Security Requirements Analysis Report

Comprehensive Security Analysis with Interactive Dashboard

Author

Security Requirements System v2.0

Published

November 25, 2025

Generated: 2025-11-25 17:05:39 Report Version: 2.0 - Comprehensive Security Analysis

1. Executive Summary

This section provides a high-level overview of the security requirements analysis, presenting key findings, validation results, and an interactive dashboard for stakeholders and decision-makers. The executive summary enables rapid comprehension of the security posture, critical risks, control coverage, and compliance status without requiring detailed technical knowledge.

1.1. Purpose and Scope

Purpose

This document presents a comprehensive security requirements analysis for the proposed application, systematically mapping high-level business requirements to specific, actionable security controls aligned with multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. The analysis provides a complete security requirements specification that guides secure system design, implementation, and verification.

Scope

This analysis encompasses all functional requirements provided, delivering comprehensive coverage across multiple security domains:

Requirements Analysis: Systematic decomposition and security-relevant extraction from business requirements
Stakeholder Analysis: Identification of stakeholders, trust boundaries, and security responsibilities
Threat Modeling: Systematic identification and assessment of security threats using STRIDE methodology
Security Control Mapping: Mapping requirements to multi-standard security controls (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed implementation guidance
Compliance Requirements: Identification of regulatory and legal compliance obligations
Architectural Security: Security architecture recommendations and design patterns
Implementation Planning: Prioritized, phased implementation roadmap
Verification Strategies: Testing and validation approaches for security controls

The analysis provides both strategic guidance for security planning and tactical details for implementation teams.

1.2. Key Findings

This section summarizes the most critical results from the security requirements analysis, providing executives and stakeholders with immediate insight into the security posture and validation status.

Analysis Metrics

Validation Score: 0.88/1.0
Validation Status: ✅ Passed
Analysis Iterations: 1
Requirements Analyzed: 20

Application Summary

A geo-centric web and mobile-optimised platform for advertising and discovering vacancies in student household sharehouses and finding compatible housemates. The system emphasises approximate-location search and map visualisation, secure mediated communication, role-based user management (advertisers, seekers, moderators, admins), automated and human moderation for safety and quality, paid-tier premium advertising with payment integration, and GDPR-compliant handling of personal data and communications while protecting exact addresses and contact details to preserve privacy and safety.

The validation score reflects the quality and completeness of the security requirements across five dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. A score of 0.8 or higher indicates that the requirements are ready for implementation, while scores below this threshold may require refinement before proceeding.

1.3. Security Overview Dashboard

This interactive dashboard provides executive-level visualization of key security metrics and trends, enabling rapid assessment of the security posture through intuitive charts and data visualizations. The dashboard presents critical information across multiple dimensions: risk distribution, security control coverage, compliance status, implementation progress, and data quality metrics. For optimal viewing experience, render this document with Quarto to enable interactive chart functionality, allowing stakeholders to explore data dynamically and drill down into specific areas of interest.

Figure 1: Risk heat map showing threat distribution by likelihood and impact (1-5 scale).

Top 5 Highest Risks:

THR-001 (Critical) - Frontend Layer - Category: Information Disclosure - Likelihood: 4 | Impact: 4 - Description: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content, favourites, or saved searches causing session token theft, account takeover, or exfiltration of PII from pages rendered

THR-006 (Critical) - Application Services (Auth/RBAC) - Category: Spoofing - Likelihood: 4 | Impact: 4 - Description: Credential stuffing, weak password reuse, or brute-force attacks leading to account takeover for advertisers or moderators. Email domain filtering for free-tier may be bypassed using disposable or com

THR-002 (High) - Frontend Layer - Category: Tampering - Likelihood: 4 | Impact: 3 - Description: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, prices, or display premium features) and submitting forged requests that rely on client-side checks (price, entitlements).

THR-009 (High) - Application Services (Moderation Pipeline) - Category: Tampering - Likelihood: 4 | Impact: 3 - Description: Adversarial content engineered to bypass automated moderation (image/text obfuscation, alternate language, unicode tricks) leading to publication of spam, scams, or malicious adverts.

THR-019 (High) - Notifications & Messaging (In-app) - Category: Denial of Service - Likelihood: 4 | Impact: 3 - Description: Messaging system spam or automated bots overwhelm a user’s inbox or notification system causing resource exhaustion and poor UX; attackers may use messaging to send harmful links.

Figure 2: Security control distribution by standard (OWASP, NIST, ISO 27001).

Figure 3: OWASP ASVS control distribution by verification category (V1-V14).

Figure 4: Security control priority distribution (Critical/High/Medium/Low).

Coverage Metrics:

Total Security Controls Mapped: 79
- OWASP ASVS: 35 controls
- NIST SP 800-53: 25 controls
- ISO 27001: 19 controls
Requirements with Security Control Mapping: 85.0% (17/20)
Average Controls per Requirement: 4.0
Critical Controls: 14 (17.7% of total)
Requirements with Verification: 100.0% (20/20)
Recommended ASVS Level: L2 (Standard)

Figure 5: Compliance status across all applicable frameworks (Red-Amber-Green rating). Shows regulatory compliance (GDPR, HIPAA, PCI-DSS, etc.) and security standards (OWASP ASVS, NIST SP 800-53, ISO 27001).

Compliance Summary:

⚠️ GDPR: In Progress (Next Audit: TBD)
❌ PCI-DSS: Gap (Next Audit: TBD)
⚠️ OWASP ASVS: In Progress (Next Audit: N/A)
⚠️ NIST SP 800-53: In Progress (Next Audit: N/A)
⚠️ ISO 27001: In Progress (Next Audit: N/A)

Figure 6: Projected implementation timeline by phase and week (based on priority-based planning).

Implementation Timeline (Projected):

Phase 1 (Critical/High): 100% projected completion (Weeks 1-8)
Phase 2 (Medium): 100% projected completion (Weeks 9-16)
Phase 3 (Low/Ongoing): Continuous improvement and monitoring

Note: Timeline is based on priority-based planning and assumes steady implementation progress.

Validation Metrics:

Overall Validation Score: ✅ 0.88/1.0

Dimension Scores:

✅ Completeness: 0.80
✅ Consistency: 0.95
✅ Correctness: 0.90
✅ Implementability: 0.80
✅ Alignment: 0.95

Figure 7: Data quality and coverage metrics.

Traceability Matrix:

Total Requirements: 20
Linked to Threats: 20 (100.0%)
Mapped to Security Controls: 17 (85.0%)
With Verification: 20 (100.0%)

Data Quality: ✅ Excellent

2. Requirements Understanding

This section presents a comprehensive analysis of the functional requirements, extracting security-relevant information and establishing the foundation for the security requirements specification. Understanding the functional requirements is essential for identifying security implications, data sensitivity, trust boundaries, and security-critical components. This analysis transforms business requirements into security-aware specifications that inform threat modeling, control selection, and compliance assessment.

2.1. High-Level Requirements Analysis

The following high-level functional requirements have been identified and analyzed for security implications:

User registration and login with role assignment and secure authentication
Email domain verification and tier-based access controls (free vs paid advertisers)
User profile management with verifiable contact display options
Advert creation, edit, delete lifecycle with support for multi-room properties
Automated and manual moderation workflow for adverts and content
Geo-centric search and filtered discovery with map visualisation (approximate locations)
Advanced filtering, saveable searches, and alerting (instant and daily digest)
Favourites/bookmarking and personalised saved-advert lists with organisation tools
Secure in-app messaging between users with optional verified contact reveal
Interactive map with clustering and approximate location display
Notifications system for adverts, messages and moderation status
Administrator and moderator dashboard for content, user and role management
Reporting and abuse-flagging system with dispute handling
Automated expiry handling and lifecycle enforcement for adverts
Paid-tier features: priority listing, branding, analytics, subscription and one-off payments
Secure payment gateway integration and payment record management
Logging, audit trails, and analytics for moderation, payments and admin actions
Privacy and data protection controls (GDPR compliance, consent management, data subject requests)
Security controls: encryption in transit and at rest, RBAC, MFA option, rate limiting and anti-abuse protections
Accessibility and mobile responsiveness (WCAG conformance target)

2.2. Detailed Requirements Breakdown

Req ID	Requirement	Business Category	Security Sensitivity	Data Classification
REQ-001	User registration and secure login with role assig…	Authentication & Authorization	High	Confidential
REQ-002	Email domain verification for free-tier advertiser…	Account Management & Verification	High	Confidential
REQ-003	User profile management capturing display name, pr…	Data Management / Privacy	Medium	Confidential
REQ-004	Advert lifecycle management: create, save draft, s…	Content Management	Medium	Public
REQ-005	Support property-level entry with multiple room en…	Data Model & Catalog	Low	Public
REQ-006	Automatic moderation/ filtering pipeline using heu…	Moderation & Safety	High	Internal
REQ-007	Moderator and Administrator dashboard to review, a…	Administration & Governance	High	Internal
REQ-008	Geo-centric search with approximate location visua…	Search & Discovery	Low	Public
REQ-009	Advanced filters: price range, distance, number of…	Search & Personalisation	Low	Public
REQ-010	Email alerts (instant and daily digest) and in-app…	Notifications & Engagement	Medium	Internal
REQ-011	Favourites/bookmarks management: allow users to fa…	User Experience & Personalisation	Low	Internal
REQ-012	Secure in-app messaging system that mediates commu…	Communication & Privacy	High	Confidential
REQ-013	Interactive map view using third-party mapping API…	Data Privacy & Visualisation	Medium	Public
REQ-014	Reporting and abuse-flagging workflow for users to…	Safety & Trust	High	Internal
REQ-015	Paid-tier features: priority listing / boosted pla…	Monetisation & Analytics	Medium	Internal
REQ-016	Secure payment processing via a PCI-DSS-compliant …	Payment Processing & Compliance	High	Restricted
REQ-017	GDPR-compliant data handling: obtain explicit cons…	Legal & Privacy	High	Confidential
REQ-018	Logging, monitoring and audit trails for authentic…	Security Operations & Forensics	High	Internal
REQ-019	Security controls including encryption in transit …	Application Security	High	Confidential
REQ-020	Accessibility and responsive design to support com…	Accessibility & UX	Low	Public

2.3. Security Context and Regulatory Obligations

Applicable regulations and obligations include: GDPR (EU/EEA/UK) for personal data processing, data subject rights and consent management; ePrivacy rules for electronic marketing and email notifications; PCI-DSS obligations for any payment card processing or token storage; national consumer protection and housing anti-discrimination laws applicable to adverts (platform should enforce non-discriminatory advertising policies); local data residency or export control laws if hosting data in or for specific jurisdictions; WCAG accessibility standards (target WCAG 2.1 AA); obligations to preserve and produce records for lawful requests (law enforcement). Platform must also consider obligations under consumer protection and payment service regulations where relevant (e.g., VAT collection, invoicing for B2B advertisers).

2.4. Assumptions

System will be cloud-hosted (public cloud) with support for region-based data residency where required.
Third-party services will be used for mapping (e.g., Google Maps, Mapbox), email delivery, and payments (PCI-compliant gateway).
Moderation combines automated tools and human moderators; moderators are trusted and trained staff with appropriate background checks.
Advertisers and users are primarily adults (18+); platform will implement age gating or explicit checks if minors are supported.
Universities will provide or have publicly available email domain lists for domain-restricted signups, or a maintainable allowlist will be created.
Users have internet access and modern browsers or mobile devices; push notifications rely on standard web/mobile push services.
Paid-tier customers will use the provided payment options and accept the platform’s terms; recurring subscription billing will be supported.
Platform will not publish exact addresses publicly; precise coordinates may be stored internally for authorised use (e.g., emergency/legal requests) with strict access controls.

2.5. Constraints

Exact addresses must not be displayed publicly — only approximate locations (neighbourhood/postcode/geohash) permitted for privacy and safety.
Integration with third-party mapping and payment providers introduces dependencies on their APIs, SLAs, and pricing.
Moderation pipeline (automated + human) may introduce publication latency; SLAs for advert approval must balance speed and safety.
Payment processing requires PCI-DSS compliance or use of a tokenizing gateway to avoid storing sensitive card data on-platform.
Data residency and local privacy regulations may require regional hosting or data segregation for EU/UK users.
Scalability and rate limiting requirements must be designed to handle dense clusters (e.g., high advert volumes in university towns) without degrading search performance.
Retention policies for logs, messages and adverts must be defined to meet legal and operational needs but may conflict with user ‘right to be forgotten’ timelines — implementation must reconcile both.
Accessibility (WCAG) and cross-browser mobile support constrain front-end frameworks and testing matrices.
Anti-abuse measures (rate limits, CAPTCHAs, content filters) must avoid impeding legitimate users while blocking bots and fraud attempts.

3. Stakeholder Analysis

This section identifies and analyzes all stakeholders involved in or affected by the system, including users, administrators, external partners, and regulatory bodies. Stakeholder analysis establishes trust boundaries, defines security responsibilities, and identifies potential security concerns from different stakeholder perspectives. Understanding stakeholder relationships and trust boundaries is critical for designing appropriate access controls, authentication mechanisms, and data protection measures.

3.1. Identified Stakeholders and User Personas

Role	Privilege Level	Trust Level	Key Security Concerns
Advertiser	User	Partially Trusted	Unverified listings leading to fraudulent adverts, unauthorized access to personal data.
Seeker	User	Partially Trusted	Phishing attacks via in-app messaging, data exposure during search.
Moderator	Admin	Trusted	Mismanagement of adverts leading to inappropriate content remaining published, insider threats.
Administrator	Admin	Trusted	Full access to user data and adverts, potential for data breaches through privilege misuse.
Agency	Paid Tier User	Partially Trusted	Misrepresentation of properties, unauthorized access to sensitive payment information.
Temporary Accommodation	Paid Tier User	Partially Trusted	Data exposure risks when handling multiple listings, potential for account misuse.
System APIs	Service Account	Trusted	Insecure API access exposing user data, improper authentication leading to unauthorized actions.
Email Notification Service	Service Account	Trusted	Data leaks through improper handling of user information, lack of consent management.
Payment Gateway	Service Account	Trusted	PCI compliance risks, potential for data breaches during transaction processing.
Mapping API	Service Account	Partially Trusted	Data exposure through unsecured API calls, insufficient access controls on location data.

3.2. Trust Model

Trust boundaries are established at the user interface, backend server, and database levels. Security mechanisms enforcing boundaries include user authentication (email/password and domain verification), role-based access control (RBAC) to ensure users can only access data and functionalities pertinent to their roles, and network segmentation to mitigate risks of unauthorized access. Advertisers can only manage their own listings, Seekers have access to search and view adverts, Moderators can approve or reject submissions, and Administrators have comprehensive management capabilities. The principle of least privilege is implemented by granting users the minimum access necessary to perform their responsibilities, thereby reducing the risk of data exposure and privilege escalation. For example, a Seeker can only view and communicate about adverts, while an Administrator has full control over user accounts and content moderation functions.

4. System Architecture Analysis

4.1. Architectural Overview

A cloud-hosted, geo-centric web and mobile platform with a layered architecture: public users access a SPA or mobile-optimised site via a CDN/WAF edge layer; requests pass through an API Gateway to Application Services (Auth/RBAC, Core API, Search/Geo engine, Moderation pipeline, Messaging, Notifications, Payments). Application services persist data to a structured relational database for adverts/users, a search index for geo/filters, and object storage for media; audit logs and analytics stream to a logging/monitoring tier. Automated moderation (heuristics/ML) and human moderator UIs enforce content safety. External integrations include mapping APIs, email/push providers, and a PCI-compliant payment gateway. Strong privacy controls (approximate locations, email domain verification, PII encryption, consent management) and role-based access protect data and operations.

4.2. Architecture Diagram

4.3. Component Breakdown

Component	Responsibility	Security Criticality	External Dependencies
Frontend Layer	Serve the SPA and mobile-optimised UI fo…	Medium	CDN/WAF, Maps API
Edge Layer	CDN and Web Application Firewall to prot…	High	Cloud CDN provider, WAF/Rate-limiting service
Application Services	Core business logic: authentication & RB…	Critical	ML/Moderation tooling (optional), Timeseries/analytics tools
Data Storage	Persistent storage for relational data (…	Critical	Cloud-managed RDBMS, Cloud object storage
External Services	Third-party integrations: maps for visua…	High	Mapbox/Google Maps, SendGrid/Mailgun or similar
Admin & Moderation	Tools and UIs for moderators and admins …	High	Identity provider for admin SSO, Audit logging/SIEM
Notifications & Messaging	In-app mediated messaging between users,…	High	Email provider, Push provider
Payments & Billing	Manage subscriptions, one-off purchases,…	Critical	PCI-DSS Payment Gateway (Stripe/Adyen), Tax/VAT services (optional)

4.4. Data Flow Analysis

Users interact via web/mobile UI which is served through a CDN/WAF. Client requests pass the API Gateway where authentication and rate-limiting occur. Authenticated requests reach Core APIs which validate input, invoke moderation checks (automated ML heuristics) and persist adverts, user profiles and room entities to the relational DB; media is uploaded to object storage and indexed into the search index (geohash/obfuscated coordinates). Search queries query the Search Index and may call geospatial services to cluster results; approximate locations are computed via geohash or centroid obfuscation before returning results to clients. Messaging is mediated by Messaging Service, storing encrypted message logs in DB and forwarding notifications to Notification Service which dispatches via email/push providers. Billing interacts with the Payment Gateway using tokenized card data; transaction metadata and audit logs are stored in DB and immutable logs. Moderation results and admin actions are logged to the audit/SIEM pipeline for retention and compliance. Data transformations include PII encryption at rest, location obfuscation, content scanning/enrichment, and payment tokenization.

4.5. Attack Surface Analysis

Primary entry points: Web/Mobile UI and Public APIs (High risk) — exposure to account takeover, XSS, CSRF, injection and abuse; mitigations: strong authentication (MFA opt-in), input validation, CSP, WAF, rate limiting and session management. Authentication endpoints (High) — risk of brute-force and credential stuffing; mitigations: password policies, MFA, anomaly detection, account lockouts, email domain checks for advertiser onboarding. File uploads/media (Medium) — risk of malware and PII leaks; mitigations: virus scanning, size/type restrictions, storage isolation, signed URLs and metadata stripping. Messaging and moderated content endpoints (High) — risk of PII leakage, harassment and phishing; mitigations: content scanning, profanity/ML filters, human moderation queue, retention and redaction policies. Search and geo APIs (Medium) — risk of data inference and scraping to discover exact addresses; mitigations: approximate geohash, rate limits, API quotas, per-request obfuscation. Payment integration (High) — PCI exposure if misconfigured; mitigations: use tokenization via PCI-compliant gateway, do not store raw card data, secure webhooks and signed callbacks. Third-party integrations (Maps/Email/Push) (Medium) — supply chain risk and data leakage; mitigations: encrypted transit, minimal scopes, contractual DPAs and monitoring. Admin/moderator UIs (High) — privileged abuse or account compromise; mitigations: SSO, strong MFA, IP restrictions, session monitoring and immutable audit logs. Logging and analytics endpoints (Medium) — risk of sensitive data in logs; mitigations: PII redaction, access controls and log encryption. Overall, major risks concentrate on authentication, moderation, payments, and data exfiltration; the defensive architecture uses layered controls (edge WAF, gateway auth, service mTLS, encryption, RBAC, monitoring) and operational controls (incident response, retention policies, privacy/consent workflows).

5. Threat Modeling

This section presents a comprehensive threat analysis of the system architecture and functional requirements. Threat modeling systematically identifies potential security vulnerabilities and attack vectors, enabling proactive risk mitigation through the application of appropriate security controls.

5.1. Threat Modeling Methodology

This analysis employs the STRIDE threat modeling methodology, a systematic framework developed by Microsoft for identifying security threats across six categories:

Spoofing Identity: Threats involving impersonation of users or systems
Tampering with Data: Threats involving unauthorized modification of data or system components
Repudiation: Threats where users deny performing actions (lack of non-repudiation)
Information Disclosure: Threats involving unauthorized access to sensitive information
Denial of Service: Threats causing disruption or unavailability of system services
Elevation of Privilege: Threats allowing unauthorized access to privileged functions

For each identified threat, the analysis evaluates likelihood (attack complexity and exposure) and impact (potential damage to confidentiality, integrity, or availability) to determine overall risk level. The methodology ensures comprehensive coverage of security concerns across all system components and interfaces.

5.2. Threat Analysis and Risk Assessment

5.2.1. Threat Overview

The following table provides a quick reference of all identified threats. Detailed analysis including descriptions, mitigation strategies, and residual risk assessment (where available) is provided in the section below.

Threat ID	Component	Category	Risk Level	Likelihood	Impact
THR-001	Frontend Layer	Information Disclosure	Critical	High	High
THR-006	Application Services (Auth/RBAC)	Spoofing	Critical	High	High
THR-002	Frontend Layer	Tampering	High	High	Medium
THR-004	Edge Layer (CDN/WAF/API Gateway)	Denial of Service	High	Medium	High
THR-005	Edge Layer (API Gateway)	Spoofing	High	Medium	High
THR-007	Application Services (Auth/RBAC)	Elevation of Privilege	High	Medium	High
THR-008	Application Services (Core API/Search/Geo)	Information Disclosure	High	Medium	High
THR-009	Application Services (Moderation Pipeline)	Tampering	High	High	Medium
THR-010	Application Services (Messaging)	Information Disclosure	High	Medium	High
THR-012	Data Storage (Relational DB / Search Index)	Information Disclosure	High	Medium	High
THR-015	External Services (Payment Gateway)	Tampering	High	Medium	High
THR-017	Admin & Moderation	Elevation of Privilege	High	Medium	High
THR-019	Notifications & Messaging (In-app)	Denial of Service	High	High	Medium
THR-021	External Services (Email Provider)	Information Disclosure	High	Low	High
THR-022	Data Storage (Backups & Logs)	Information Disclosure	High	Medium	High
THR-023	Frontend / Edge (CDN)	Information Disclosure	High	Low	High
THR-024	Application Services / API	Tampering	High	Medium	High
THR-027	External Services (Third-party Integrations overall)	Information Disclosure	High	Medium	High
THR-029	Infrastructure / Cloud	Tampering	High	Medium	High
THR-003	Frontend Layer	Spoofing	Medium	Medium	Medium
THR-011	Notifications & Messaging (Email/Push Providers)	Information Disclosure	Medium	Medium	Medium
THR-013	Data Storage (Object Storage for Media)	Information Disclosure	Medium	Medium	Medium
THR-014	External Services (Maps API)	Information Disclosure	Medium	Medium	Medium
THR-016	Payments & Billing	Repudiation	Medium	Medium	Medium
THR-018	Admin & Moderation	Repudiation	Medium	Medium	Medium
THR-020	Application Services (Search/Geo)	Tampering	Medium	Medium	Medium
THR-025	Application Services (API)	Spoofing	Medium	Medium	Medium
THR-026	Payments & Billing	Repudiation	Medium	Low	Medium
THR-028	Platform-wide (Account Creation & Email Domain Filtering)	Spoofing	Medium	Medium	Medium
THR-030	Platform-wide (Search & Saved Searches / Alerts)	Information Disclosure	Medium	Low	Medium

Total Threats Identified: 30

5.2.2. Detailed Threat Analysis

This section provides comprehensive analysis of each identified threat, including descriptions, mitigation strategies, and residual risk assessment (where controls have been evaluated). Threats are organized by risk level for prioritized review.

Critical Risk Threats

THR-001 - Frontend Layer

Category: Information Disclosure
Likelihood: High | Impact: High
Initial Risk Level: Critical
Description: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content, favourites, or saved searches causing session token theft, account takeover, or exfiltration of PII from pages rendered in other users’ browsers.
Mitigation Strategy: Apply strict output encoding/escaping for all user content, use a secure templating engine, implement Content Security Policy (CSP) restricting script sources, sanitize HTML with a safe whitelist or disallow HTML, mark session cookies HttpOnly and SameSite=strict; conduct automated and manual security testing (SAST/DAST).
Controls Applied: CSP, Input Validation, Output Encoding, HttpOnly/SameSite Cookies, SAST/DAST
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-006 - Application Services (Auth/RBAC)

Category: Spoofing
Likelihood: High | Impact: High
Initial Risk Level: Critical
Description: Credential stuffing, weak password reuse, or brute-force attacks leading to account takeover for advertisers or moderators. Email domain filtering for free-tier may be bypassed using disposable or compromised university addresses.
Mitigation Strategy: Implement rate-limited login attempts, account lockouts with progressive delays, MFA (mandatory for moderators/admins and encouraged for advertisers), password strength policy, monitor for credential stuffing via IP reputation and breached-password checks; verify university domain via domain MX checks and time-limited email verification tokens.
Controls Applied: MFA, Rate Limiting, Breached Password Checks, Email Domain Verification
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

High Risk Threats

THR-002 - Frontend Layer

Category: Tampering
Likelihood: High | Impact: Medium
Initial Risk Level: High
Description: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, prices, or display premium features) and submitting forged requests that rely on client-side checks (price, entitlements).
Mitigation Strategy: Enforce server-side authorization and validation for all business-critical operations (price changes, entitlement checks). Sign client-visible configuration where needed, validate inputs on server, and log suspicious client-side anomalies.
Controls Applied: Server-side Authorization, Request Validation, Integrity Checks
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-004 - Edge Layer (CDN/WAF/API Gateway)

Category: Denial of Service
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or advert submission endpoints to degrade availability and impact revenue and user confidence.
Mitigation Strategy: Use CDN + WAF with adaptive rate-limiting and geo-blocking, API Gateway throttling per IP and per-account, autoscaling backend, CAPTCHA for suspicious flows (advert creation), traffic anomaly detection and scrubbing service.
Controls Applied: WAF, Rate Limiting, Autoscaling, DDoS Mitigation Service
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-005 - Edge Layer (API Gateway)

Category: Spoofing
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Replay attacks or token theft in transit due to inadequate transport security or poor token handling (long-lived tokens, insecure storage on client) leading to account hijacking.
Mitigation Strategy: Enforce TLS 1.2+/HSTS, short-lived access tokens with refresh tokens stored securely, require token binding if possible, use OAuth 2.0 best practices, revoke tokens on suspicious activity, secure local storage (avoid persistent tokens in localStorage), implement device/session fingerprinting and MFA for sensitive actions.
Controls Applied: TLS, OAuth2, Short-lived Tokens, MFA
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-007 - Application Services (Auth/RBAC)

Category: Elevation of Privilege
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Broken access control allowing privilege escalation (e.g., seeker modifies request to set ‘role=moderator’ or uses API endpoints reserved for admin to approve adverts).
Mitigation Strategy: Enforce server-side RBAC checks for every sensitive endpoint, implement deny-by-default ACLs, use centralized authorization library, detailed audit logging of role changes, review admin endpoints manually and require MFA/SSO for admin actions.
Controls Applied: RBAC, Centralized Authorization, Admin MFA/SSO, Audit Logging
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-008 - Application Services (Core API/Search/Geo)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Exposure of exact addresses or PII via search index or API responses (e.g., detailed coordinates leaked in map tile queries or in metadata exposed in API), undermining privacy requirement of approximate locations.
Mitigation Strategy: Implement server-side fuzzing/geo-obfuscation before storing/searching; strip exact coordinates from public search results, only store precise addresses encrypted and available to authorized parties, review third-party map integrations so they only receive approximate coordinates, log and monitor access to precise location fields.
Controls Applied: Field-level Encryption, Geo-obfuscation, Least Privilege Access, Third-party Data Minimization
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-009 - Application Services (Moderation Pipeline)

Category: Tampering
Likelihood: High | Impact: Medium
Initial Risk Level: High
Description: Adversarial content engineered to bypass automated moderation (image/text obfuscation, alternate language, unicode tricks) leading to publication of spam, scams, or malicious adverts.
Mitigation Strategy: Use layered moderation: ML heuristics + deterministic rules + human review for flagged or high-risk adverts; adversarial testing of moderation models; limit feature exposure for new/low-reputation advertisers; rate-limit advert creation.
Controls Applied: Automated Moderation, Human-in-the-loop, Adversarial Testing, Rate Limiting
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-010 - Application Services (Messaging)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: In-app moderated messaging used to exchange PII; messages stored in DB and in transit may be exposed due to weak encryption, improper RBAC, or logging of message bodies to analytics systems.
Mitigation Strategy: Encrypt messages at rest with KMS-managed keys, enforce TLS in transit, restrict access to message stores to smallest set of service accounts, redact PII in analytics pipelines, provide ephemeral message retention policies and user-controlled deletion, log only metadata not message contents.
Controls Applied: TLS, At-rest Encryption (KMS), RBAC, PII Redaction
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-012 - Data Storage (Relational DB / Search Index)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Unauthorized access to backups, snapshots, or misconfigured search index (Elasticsearch/OpenSearch) exposing full dataset including PII or sensitive adverts.
Mitigation Strategy: Enforce network-level access controls (VPC, private endpoints), enable authentication and TLS on search services, encrypt backups at rest, rotate access keys, restrict snapshot exports, and monitor/access alerts for unusual data exports.
Controls Applied: Network ACLs, Encryption at Rest, Access Controls, Monitoring/Alerts
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-015 - External Services (Payment Gateway)

Category: Tampering
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Payment flow manipulation or token interception causing fraudulent premium listings, subscription status manipulation, or chargeback/fraud against the platform.
Mitigation Strategy: Use PCI-compliant gateway with tokenization (never store raw card data), validate webhooks with signatures, verify payment notification origins, reconcile subscription state server-side, implement fraud detection and anomaly monitoring, require 3DS where supported.
Controls Applied: PCI-DSS Payment Gateway, Webhook Signing, Server-side Reconciliation, Fraud Detection
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-017 - Admin & Moderation

Category: Elevation of Privilege
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Compromise of admin/moderator accounts via phishing or weak SSO config leading to mass approval of malicious adverts, deletion or tampering with audit logs, or user bans.
Mitigation Strategy: Use strong SSO with MFA, enforce least privilege for moderator roles (separation of duties), require justification and second approval for bulk actions, record all admin actions to immutable audit logs, and monitor for anomalous admin activity.
Controls Applied: SSO with MFA, Least Privilege, Immutable Audit Logs, Two-person Review for Critical Actions
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-019 - Notifications & Messaging (In-app)

Category: Denial of Service
Likelihood: High | Impact: Medium
Initial Risk Level: High
Description: Messaging system spam or automated bots overwhelm a user’s inbox or notification system causing resource exhaustion and poor UX; attackers may use messaging to send harmful links.
Mitigation Strategy: Rate-limit message sending per account/IP, implement reputation scoring for senders, CAPTCHAs on account actions, automated content filtering, allow users to block/report senders, throttle notifications and use backpressure in queueing system.
Controls Applied: Rate Limiting, Reputation System, CAPTCHA, Content Filtering
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-021 - External Services (Email Provider)

Category: Information Disclosure
Likelihood: Low | Impact: High
Initial Risk Level: High
Description: Compromise or misconfiguration at the email provider leading to leakage of verification emails, digests, or password resets enabling account takeover or exposure of PII.
Mitigation Strategy: Use reputable ESP with secure contracts, enable TLS and DKIM/SPF/DMARC, minimize sensitive data in emails, send reset links that expire quickly, monitor ESP security advisories, and have incident response plan for ESP compromise.
Controls Applied: TLS, DKIM/SPF/DMARC, ESP SLA Review
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-022 - Data Storage (Backups & Logs)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Backups or audit logs containing historic PII retained longer than necessary, or accessible by excessive staff, leading to compliance violations (GDPR) and data breach risks.
Mitigation Strategy: Apply data retention policies and automated deletion, anonymize/pseudonymize PII where possible, restrict access to backups via IAM, encrypt backups, and periodically audit access to retention stores.
Controls Applied: Data Retention Policy, Encryption, Access Controls
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-023 - Frontend / Edge (CDN)

Category: Information Disclosure
Likelihood: Low | Impact: High
Initial Risk Level: High
Description: Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pages cached publicly) exposing PII or private adverts to other users.
Mitigation Strategy: Use cache-control headers to prevent caching of personalized content, vary cache on headers appropriately, use CDN configuration to strip sensitive cookies/headers, and test CDN caching rules for unintended caching.
Controls Applied: Cache-Control Headers, CDN Configuration Review
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-024 - Application Services / API

Category: Tampering
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Injection attacks (SQL injection or NoSQL injection) via poorly validated advert fields or search parameters allowing data tampering, unauthorized data access, or remote code execution via unsafe ORM usage.
Mitigation Strategy: Use parameterized queries/ORM safe APIs, validate and constrain inputs (length/format), ORM prepared statements, adopt least-privilege DB accounts, run regular SAST/DAST and DB access monitoring, and protect admin endpoints behind stricter controls.
Controls Applied: Parameterized Queries, Input Validation, SAST/DAST
Control Effectiveness: High
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-027 - External Services (Third-party Integrations overall)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Over-sharing of PII to third-party analytics, logging, or ML moderation providers (sending full message bodies or exact addresses) creating compliance and privacy risk.
Mitigation Strategy: Data minimization: pseudonymize or aggregate before sending, use contracts and DPA with providers, vet security posture of providers, encrypt data in transit and at rest, and implement strict access controls on provider integrations.
Controls Applied: Data Minimization, DPA/Contracts, Pseudonymization
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

THR-029 - Infrastructure / Cloud

Category: Tampering
Likelihood: Medium | Impact: High
Initial Risk Level: High
Description: Cloud misconfigurations (open management ports, overly permissive IAM roles, publicly exposed DB or storage) allowing attackers to access or modify data and resources.
Mitigation Strategy: Implement IaC with security scanning, enforce least-privilege IAM, use VPC/private endpoints, rotate credentials, use cloud provider security posture management (CSPM), run periodic pen tests and configuration audits, and enable multi-account separation for prod/staging.
Controls Applied: Least-Privilege IAM, CSPM, IaC Scanning, Network Segmentation
Control Effectiveness: Medium
Residual Risk Level: Medium
Status: ⚠️ Requires Review

Medium Risk Threats

THR-003 - Frontend Layer

Category: Spoofing
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: UI-level phishing via malicious adverts or profiles that mimic platform branding to trick users into revealing credentials or off-platform contact details.
Mitigation Strategy: Restrict HTML/branding in adverts, enforce a platform watermark and verified-badge UI for verified advertisers, run automated moderation for suspicious branding, user education and reporting flow, and block off-platform contact until verification.
Controls Applied: Automated Moderation, Verified Badges, User Reporting
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ⚠️ Requires Review

THR-011 - Notifications & Messaging (Email/Push Providers)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Sensitive information leaked via email digests or push notifications (e.g., full advert addresses, private messages) or email interception due to misconfigured email provider templates exposing PII.
Mitigation Strategy: Limit content in notifications to non-sensitive summaries, avoid including PII or exact location in emails/pushes, use secure provider configurations (TLS for SMTP, signed DKIM/SPF), allow users to opt-out of email content sharing, and review templates for accidental leakage.
Controls Applied: Template Review, TLS for Email, Notification Content Policy
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-013 - Data Storage (Object Storage for Media)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Publicly accessible S3/Blob containers containing photos that include metadata or people could be exposed due to incorrect ACLs or predictable object URLs.
Mitigation Strategy: Use private buckets with signed, time-limited URLs for media access, strip EXIF/GPS metadata from uploaded photos, scan uploads for sensitive content, enforce upload size/content checks, and set least-privilege IAM policies for storage access.
Controls Applied: Signed URLs, EXIF Stripping, Private Buckets, IAM Policies
Control Effectiveness: High
Residual Risk Level: Low
Status: ✅ Accepted

THR-014 - External Services (Maps API)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Third-party map provider logs or telemetry reveal approximate queries or leak location metadata (e.g., passing exact coords), or attacker abuses API keys embedded in frontend to query map endpoints for data enumeration.
Mitigation Strategy: Send only obfuscated/approximate coordinates to map provider, restrict API keys via referer/IP restrictions, avoid embedding privileged keys in client, use server-side map proxy for sensitive queries, review provider’s privacy SLA.
Controls Applied: API Key Restriction, Server-side Proxy, Coordinate Obfuscation
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-016 - Payments & Billing

Category: Repudiation
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Advertisers dispute charges or claim service not delivered; lack of reliable invoice/transaction audit trail hinders dispute resolution and may lead to financial loss.
Mitigation Strategy: Maintain tamper-evident audit logs for billing events, store payment tokenization metadata, send receipts with transaction IDs, enable immutable logs in SIEM, and retain reconciliation records per compliance retention policies.
Controls Applied: Immutable Audit Logs, Receipt/Invoice Records, SIEM
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-018 - Admin & Moderation

Category: Repudiation
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Insufficient or tamperable audit logs allowing admins/moderators to deny or hide actions (e.g., disabling adverts without reason), impacting incident response and compliance.
Mitigation Strategy: Use append-only, write-once audit logging (cloud-native immutability), forward logs to SIEM with restricted access, implement logging integrity checks, and enforce log retention/rotation policies for compliance.
Controls Applied: Immutable Logging, SIEM, RBAC on Logs
Control Effectiveness: High
Residual Risk Level: Low
Status: ✅ Accepted

THR-020 - Application Services (Search/Geo)

Category: Tampering
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Search index poisoning or malicious adverts crafted to manipulate search ranking (e.g., SEO spam, repeated adverts to surface malicious listings), reducing quality and user trust.
Mitigation Strategy: Rate-limit advert creation, use deduplication checks, reputation-based ranking and human review for new advertisers, monitor ranking changes, and use anomaly detection in search metrics.
Controls Applied: Rate Limiting, Reputation-based Ranking, Index Integrity Checks
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-025 - Application Services (API)

Category: Spoofing
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: API key leakage or abuse (e.g., frontend-embedded keys used to query private endpoints or enumerate adverts), enabling attackers to harvest data or bypass quotas.
Mitigation Strategy: Never embed privileged keys in frontend, restrict keys by origin/IP and scope, rotate keys regularly, monitor key usage and set quotas, and require server-side calls for privileged operations.
Controls Applied: Key Rotation, Key Restrictions, Monitoring
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-026 - Payments & Billing

Category: Repudiation
Likelihood: Low | Impact: Medium
Initial Risk Level: Medium
Description: Lack of immutable proof for subscription entitlement changes leads to disputes where advertisers claim upgrades/downgrades were not applied correctly or were fraudulent.
Mitigation Strategy: Record subscription lifecycle events immutably with timestamps, require server-side confirmation flows for entitlements, keep audit trails tied to payment gateway transaction IDs, and notify users on entitlement changes.
Controls Applied: Immutable Audit Trail, Server-side Entitlement Enforcement
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-028 - Platform-wide (Account Creation & Email Domain Filtering)

Category: Spoofing
Likelihood: Medium | Impact: Medium
Initial Risk Level: Medium
Description: Bypass of email-domain verification for free-tier advertisers using disposable university-like addresses or compromised student mailbox leading to fraudulent adverts.
Mitigation Strategy: Perform MX record checks and restrict to known university domains list, implement additional checks (SAML/IdP integration with select institutions), manual/automated scrutiny for new advertiser accounts, rate-limit new accounts, and use reputation scoring before granting free-tier privileges.
Controls Applied: MX Verification, Known Domain Allowlist, SAML/Institutional SSO
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

THR-030 - Platform-wide (Search & Saved Searches / Alerts)

Category: Information Disclosure
Likelihood: Low | Impact: Medium
Initial Risk Level: Medium
Description: Saved searches and alert digest emails could be inferred by attackers to profile a user’s activity or to stalk users (e.g., frequent queries for a person’s name or location patterns).
Mitigation Strategy: Protect saved search metadata with proper ACLs, encrypt saved filters in DB if sensitive, allow users to opt-out of instant alerts, aggregate digest emails, and rate-limit alerts per user to prevent metadata leakage.
Controls Applied: ACLs, Encryption of User Metadata, User Privacy Controls
Control Effectiveness: Medium
Residual Risk Level: Low
Status: ✅ Accepted

Risk Reduction Summary:

Critical Risk Reduction: 2 threats reduced from Critical to lower levels
High Risk Reduction: 17 threats reduced from High to lower levels
Residual Risk Distribution: 0 threats remain at Critical/High level

5.3. Risk Summary

The most critical threats are account compromise (THR-006), XSS and client-side attacks (THR-001), exposure of PII/location data via storage or third-party integrations (THR-008, THR-012, THR-027), and payment-related fraud or token manipulation (THR-015). Attackers can enter via credential stuffing, injection vectors, third-party API key leakage, misconfigured cloud services, or by exploiting moderation gaps. Availability risks (DDoS against search/messaging — THR-004) also present high business impact. Priority controls: enforce strong authentication/MFA and centralized RBAC for admin functions; server-side input validation and parameterized queries; encryption-at-rest and field-level encryption for PII; strict handling of geolocation (server-side obfuscation and minimal sharing with map providers); implement WAF and API Gateway rate-limiting; use PCI-compliant payment tokenization and webhook verification; use layered moderation (ML + human review) and content sanitization; and operational controls such as least-privilege IAM, CSPM, immutible audit logging, and incident detection/response with SIEM. Overall risk posture is moderate-high: multiple high-impact vectors exist but can be materially reduced by implementing the above prioritized controls. Immediate attention should focus on account and admin protection (MFA, SSO hardening, RBAC), preventing PII leakage (encryption, obfuscation, third-party minimization), secure payment integration, and robust moderation and anti-abuse measures.

6. Multi-Standard Security Requirements Mapping

This section maps each functional requirement to specific security controls from multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. This multi-standard approach provides comprehensive coverage across application-level, enterprise-level, and organizational-level security domains:

OWASP ASVS: Application-level security controls (code, APIs, authentication, session management)
NIST SP 800-53: Enterprise security controls (governance, risk management, incident response)
ISO 27001: Information security management controls (policies, procedures, organizational controls)

Requirements are prioritized based on risk assessment and compliance needs, with controls selected from the most appropriate standard(s) for each requirement type.

6.1. Recommended ASVS Compliance Level

Recommended Level: L2

Level 2: Standard

Recommended for most production applications. Provides comprehensive security coverage suitable for applications handling sensitive data or operating in regulated environments. Includes controls for authentication, authorization, data protection, and secure communications.

The recommendation considers factors such as:

Data sensitivity and classification levels
Regulatory and compliance requirements (GDPR, HIPAA, PCI-DSS, etc.)
Threat landscape and risk assessment from threat modeling
Business criticality and potential impact of security incidents

All security controls referenced in this document align with this recommended compliance level.

6.2. Requirements Mapping

This section maps each high-level requirement to specific security controls from multiple standards (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed descriptions, relevance explanations, and integration guidance. Controls are grouped by standard for clarity.

6.2.1. REQ-1: User registration and login with role assignment and secure authentication

OWASP ASVS Controls

V2.1.1

Requirement: Verify that user registration and login mechanisms require robust authentication, including secure password handling and account lifecycle management.

Relevance: Covers secure authentication during registration and login, ensuring robust password practices. Aligns directly with role assignment by enforcing strong authentication before authorization decisions.

Integration Tips: Implement password hashing with a modern algorithm (e.g., Argon2id, bcrypt) and enforce complexity and lockout policies. Ensure account lifecycle includes activation, lock, recovery workflows with secure tokens.

Verification Method: Review auth flow design, inspect password storage configuration, and test registration/login including account lifecycle.

Level: L1 | Priority: Critical

V4.1.1

Requirement: Verify that a role-based access control (RBAC) or attribute-based access control (ABAC) scheme is enforced at the application level for all protected resources.

Relevance: Addresses role assignment and enforcement across resources, essential for separating user capabilities. Ensures authorization checks are centralized and consistent.

Integration Tips: Define roles and permissions in a policy store and enforce checks server-side on every request. Use middleware/filters to guard endpoints and include role claims in access tokens.

Verification Method: Policy review, code inspection of authorization middleware, and role-based access tests.

Level: L1 | Priority: Critical

NIST SP 800-53 Controls

IA-2

Requirement: Identify and authenticate organizational users (and/or processes acting on behalf of users).

Relevance: Ensures all users are uniquely identified and authenticated before accessing the system. Underpins secure login and session establishment.

Integration Tips: Use unique user IDs, enforce strong authenticators, and bind sessions/tokens to authenticated identities. Log authentication attempts and outcomes.

Verification Method: Inspect identity provider configuration, review auth logs, and perform positive/negative login tests.

Priority: Critical

ISO 27001:2022 Controls

A.9.2.3

Requirement: The provisioning of user access rights shall be formalized, including assignment of access rights to all types of users for all systems and services.

Relevance: Formalizes role assignment processes and approvals to prevent excessive privileges. Supports onboarding and changes in user roles.

Integration Tips: Implement joiner-mover-leaver workflows with approvals and documented RBAC matrices. Periodically review access rights and automate provisioning via IAM.

Verification Method: Review access provisioning SOPs, sampling of access requests, and RBAC review records.

Priority: High

6.2.2. REQ-2: Email domain verification and tier-based access controls (free vs paid advertisers)

OWASP ASVS Controls

V2.2.3

Requirement: Verify that the application verifies the ownership of an email address or phone number during registration and prior to activation.

Relevance: Directly maps to verifying email ownership before granting access or features. Prevents fake or unverified accounts from accessing tiers.

Integration Tips: Send signed, single-use, time-limited verification links and require completion before enabling account. Track verification status and block feature access until verified.

Verification Method: Functional tests of email verification flow and review of token expiry/one-time use implementation.

Level: L2 | Priority: High

V4.2.1

Requirement: Verify that access controls enforce authorization decisions based on the authenticated user’s role or attributes.

Relevance: Supports tier-based access by enforcing decisions tied to attributes such as subscription status. Ensures paid features are limited to authorized users.

Integration Tips: Model tier as user attributes/claims and enforce checks in controllers/services. Use policy-based authorization to centralize logic.

Verification Method: Review authorization policies and test scenarios for free vs paid users.

Level: L1 | Priority: Critical

NIST SP 800-53 Controls

AC-2

Requirement: Manage information system accounts, including establishing, activating, modifying, disabling, and removing accounts.

Relevance: Provides governance for account status changes tied to subscription lifecycle (e.g., downgrades, suspensions). Ensures only active, verified accounts access tiers.

Integration Tips: Automate activation post-verification, suspend on non-payment, and remove access on subscription end. Maintain audit trails for account state changes.

Verification Method: Review account lifecycle automation and audit logs for state transitions.

Priority: High

ISO 27001:2022 Controls

A.9.1.2

Requirement: Users shall only be provided with access to the network and network services that they have been specifically authorized to use.

Relevance: Supports restricting platform services to the appropriate tier. Ensures least privilege across service boundaries.

Integration Tips: Segment paid-tier services and enforce service-level authorization checks. Configure API gateways to evaluate tier claims.

Verification Method: Review service access configurations and test unauthorized access attempts.

Priority: Medium

6.2.3. REQ-3: User profile management with verifiable contact display options

OWASP ASVS Controls

V1.4.3

Requirement: Verify that the application collects and processes only the minimum amount of personal data necessary and provides users control over data sharing.

Relevance: Ensures profiles collect minimal data and provide controls for showing/hiding verified contacts. Reduces exposure and supports user choice.

Integration Tips: Design profile fields as optional where possible, and include per-field visibility toggles. Avoid storing unnecessary contact data.

Verification Method: Design review and UX testing of privacy controls; data inventory check for minimization.

Level: L2 | Priority: High

V9.1.1

Requirement: Verify that the application protects personal data and supports data minimization consistent with privacy requirements.

Relevance: Classifies profile contact data as personal and enforces appropriate protections. Aligns with display options and minimization.

Integration Tips: Mark contact fields as sensitive and apply encryption and access restrictions. Ensure logs do not expose contact details.

Verification Method: Review data classification and storage protections; check logs for PII leakage.

Level: L1 | Priority: High

NIST SP 800-53 Controls

AC-6

Requirement: Employ the principle of least privilege, allowing only authorized access for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks.

Relevance: Restricts who can view or modify profile and contact data. Supports controlled display options and backend enforcement.

Integration Tips: Enforce per-user and per-field access checks in APIs. Limit support/admin tools to read-only unless explicitly approved.

Verification Method: Access tests for different roles and review of API authorization rules.

Priority: High

ISO 27001:2022 Controls

A.18.1.4

Requirement: Privacy and protection of personally identifiable information shall be ensured as required in relevant legislation and regulation.

Relevance: PII in user profiles and contact details must be protected and processed lawfully. Governs how contact info is displayed and shared.

Integration Tips: Document lawful bases, implement consent where needed, and restrict display of PII via user-controlled settings. Apply masking by default.

Verification Method: Review privacy documentation, data flows, and UI settings for PII exposure.

Priority: Critical

6.2.5. REQ-5: Automated and manual moderation workflow for adverts and content

OWASP ASVS Controls

V7.1.1

Requirement: Verify that all security-relevant events are logged, including authentication, authorization decisions, and administrative actions.

Relevance: Moderation is an administrative function requiring comprehensive logging. Enables forensic review and dispute resolution.

Integration Tips: Instrument moderation services to emit structured logs and centralize them. Protect logs with RBAC and integrity controls.

Verification Method: Check logging configuration and attempt to access logs with different roles.

Level: L1 | Priority: High

NIST SP 800-53 Controls

AU-3

Requirement: Ensure that audit records contain information that establishes what events occurred, the sources of the events, and the outcomes of the events.

Relevance: Moderation actions must be auditable to trace who approved/rejected content and why. Supports accountability in workflows.

Integration Tips: Log moderation events with actor ID, object, action, reason, and outcome. Use immutable storage or WORM where feasible.

Verification Method: Review audit log fields and sample records for completeness.

Priority: High

AU-6

Requirement: Review and analyze information system audit records for indications of inappropriate or unusual activity and report findings.

Relevance: Requires active analysis of moderation logs for abuse or errors. Supports both automated alerts and manual oversight.

Integration Tips: Create dashboards for moderation KPIs and anomaly detection. Define escalation paths for suspicious patterns.

Verification Method: Inspect SIEM dashboards and alert configurations for moderation events.

Priority: Medium

ISO 27001:2022 Controls

A.12.4.1

Requirement: Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed.

Relevance: Mandates ongoing review of moderation-related logs to detect issues or abuse. Complements automated and manual workflows.

Integration Tips: Establish review schedules and alerts for moderation anomalies (e.g., high rejection rate by a user). Document procedures.

Verification Method: Review log review procedures and evidence of periodic reviews.

Priority: Medium

6.2.6. REQ-6: Geo-centric search and filtered discovery with map visualisation (approximate locations)

OWASP ASVS Controls

V1.4.2

Requirement: Verify that the application limits collection and retention of location and other sensitive data to the minimum necessary.

Relevance: Approximate locations reduce privacy risks in map visualisation. Control mandates limiting collection/retention of geodata.

Integration Tips: Store coarse geohashes instead of exact coordinates and purge old location data per retention policy. Disable location logging by default.

Verification Method: Review data model and retention jobs; verify only approximate location is exposed.

Level: L2 | Priority: High

V9.4.1

Requirement: Verify that sensitive data such as geolocation is not exposed in logs or through APIs beyond what is necessary for business purposes.

Relevance: Prevents leakage of exact locations via logs or APIs during geo search and filters. Aligns to privacy-by-design.

Integration Tips: Mask or omit exact lat/long in API responses and redact in logs. Implement schema-level allowlists for fields.

Verification Method: API response and log sampling to confirm no precise coordinates are present.

Level: L1 | Priority: High

NIST SP 800-53 Controls

PL-8

Requirement: Develop an information security architecture for the system that describes the requirements and approach to protect organizational information.

Relevance: Ensures geo features are designed with security/privacy controls embedded. Guides architecture for map services and data flows.

Integration Tips: Document data flows for geo queries, caching, and third-party maps. Include threat modeling for location privacy.

Verification Method: Review security architecture documents and threat models covering geo components.

Priority: Medium

ISO 27001:2022 Controls

A.18.1.5

Requirement: Cryptographic controls shall be used in compliance with all relevant agreements, legislation and regulations.

Relevance: Map data transfer and storage may require cryptographic protections, especially for location data. Ensures compliant crypto usage.

Integration Tips: Use TLS for map APIs and encrypt sensitive caches at rest. Maintain cipher suites in line with policy.

Verification Method: Crypto configuration review and TLS scanning of map endpoints.

Priority: Medium

6.2.7. REQ-7: Advanced filtering, saveable searches, and alerting (instant and daily digest)

OWASP ASVS Controls

V10.4.1

Requirement: Verify that the application enforces business logic with appropriate limits and thresholds (e.g., rate limits) to prevent abuse.

Relevance: Alerting features can be abused for spam or resource exhaustion; rate limits mitigate abuse. Controls align with business logic enforcement.

Integration Tips: Apply per-user and per-destination quotas for alerts and digests. Implement backoff and queue throttling.

Verification Method: Review rate limit configurations and simulate high-frequency alert creation.

Level: L2 | Priority: High

V5.4.3

Requirement: Verify that untrusted data is properly sanitized and output encoded to prevent injection in notifications and alerts.

Relevance: Search filters and results may be reflected in notifications; encoding prevents injection in emails/push messages.

Integration Tips: Template notifications with strict encoding and avoid HTML from users. Validate and sanitize saved search names/criteria.

Verification Method: Review templates and perform injection tests in alert content.

Level: L1 | Priority: High

NIST SP 800-53 Controls

SI-4

Requirement: Monitor the information system to detect attacks and indicators of potential attacks.

Relevance: Monitoring helps detect alerting abuse or anomalous filter activity. Supports operational security of alert pipelines.

Integration Tips: Create alerts for unusual spikes in alert generation or delivery failures. Feed logs into SIEM for correlation.

Verification Method: Check monitoring rules and SIEM dashboards for alerting subsystem.

Priority: Medium

ISO 27001:2022 Controls

A.12.1.3

Requirement: The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure system performance.

Relevance: Digest and alert jobs can impact capacity; capacity management ensures stability and prevents DoS-like conditions.

Integration Tips: Track queue sizes and throughput; auto-scale workers. Schedule digests to spread load.

Verification Method: Review capacity dashboards and auto-scaling policies.

Priority: Low

6.2.9. REQ-9: Secure in-app messaging between users with optional verified contact reveal

OWASP ASVS Controls

V9.2.1

Requirement: Verify that all sensitive communications are encrypted in transit using secure protocols.

Relevance: In-app messaging contains sensitive content and must be protected in transit. Prevents eavesdropping and tampering.

Integration Tips: Enforce TLS 1.2+ for APIs and websockets; use HSTS. Validate certificates and pin where appropriate.

Verification Method: TLS configuration scan and packet inspection to confirm encryption.

Level: L1 | Priority: Critical

V2.8.1

Requirement: Verify that re-authentication or step-up authentication is required before performing sensitive actions such as revealing personal contact details.

Relevance: Optional contact reveal is a sensitive action that should require step-up checks. Reduces risk of unauthorized exposure.

Integration Tips: Prompt for password/MFA re-check before revealing contact info. Use short-lived tokens to authorize the reveal action.

Verification Method: Functional test of step-up flow and token expiry behavior.

Level: L2 | Priority: High

NIST SP 800-53 Controls

SC-13

Requirement: Employ cryptographic mechanisms to prevent unauthorized disclosure of information and detect changes to information during transmission.

Relevance: Mandates robust cryptographic protections for messaging channels. Supports integrity and confidentiality of messages.

Integration Tips: Use authenticated encryption ciphersuites; consider message signing if end-to-end requirements exist.

Verification Method: Review cipher suites and test integrity verification on message transport.

Priority: High

ISO 27001:2022 Controls

A.13.2.3

Requirement: Information involved in electronic messaging shall be appropriately protected.

Relevance: Establishes organizational requirements to safeguard messaging data at rest and in transit. Covers policies and controls.

Integration Tips: Define retention limits, enable encryption at rest for message stores, and restrict admin access to message content.

Verification Method: Policy review and storage configuration checks; access audit for admin views.

Priority: Medium

6.2.10. REQ-10: Interactive map with clustering and approximate location display

OWASP ASVS Controls

V1.4.1

Requirement: Verify that privacy requirements such as data minimization and anonymization are addressed in the design.

Relevance: Approximate location display should anonymize user locations. Ensures privacy considerations are built into map features.

Integration Tips: Use aggregation/clustering thresholds and snap points to grids to avoid pinpointing exact addresses. Avoid storing raw coordinates in the client.

Verification Method: Design review and UI tests to confirm only approximate positions are shown.

Level: L1 | Priority: High

V5.3.1

Requirement: Verify that data rendered in the UI, including maps and visualizations, is properly encoded to prevent injection.

Relevance: Map popups and labels may render user-supplied data; encoding prevents XSS in map visualizations.

Integration Tips: Sanitize and encode all map label fields and disable HTML where possible. Use safe templating APIs.

Verification Method: Dynamic application security testing for XSS in map components.

Level: L1 | Priority: High

NIST SP 800-53 Controls

SC-7

Requirement: Monitor and control communications at the external boundary and key internal boundaries of the system.

Relevance: External map tiles/APIs often cross system boundaries; boundary protection controls access and monitoring.

Integration Tips: Route third-party map calls through controlled egress with allowlists and API keys vaulting. Monitor outbound traffic.

Verification Method: Network configuration review and monitoring of egress to mapping services.

Priority: Medium

ISO 27001:2022 Controls

A.14.2.1

Requirement: Rules for the development of software and systems shall be established and applied to developments within the organization.

Relevance: Ensures secure coding and review standards apply to map components. Reduces vulnerabilities in interactive UIs.

Integration Tips: Adopt secure coding guidelines for frontend visualization and perform code reviews. Include threat modeling for map features.

Verification Method: Check SDLC policy adherence and code review records for map modules.

Priority: Low

6.2.11. REQ-11: Notifications system for adverts, messages and moderation status

OWASP ASVS Controls

V10.4.2

Requirement: Verify that the application enforces anti-automation controls such as rate limiting for notification-triggering actions.

Relevance: Notifications can be abused for spamming or DoS; rate limiting protects system and users. Critical for user-triggered alerts.

Integration Tips: Throttle per user and per recipient address; implement CAPTCHA/anti-automation on high-risk endpoints.

Verification Method: Review rate limiting middleware configuration and attempt burst notification generation.

Level: L2 | Priority: High

V7.1.2

Requirement: Verify that logging includes sufficient detail to identify the subject, action, object, timestamp, and outcome for security-relevant events.

Relevance: Notification events, especially moderation status changes, need detailed logs for troubleshooting and audits.

Integration Tips: Ensure structured logging of notification sends, failures, and user actions with correlation IDs.

Verification Method: Review sample logs for required fields and correlation.

Level: L2 | Priority: Medium

NIST SP 800-53 Controls

SI-10

Requirement: Check the validity of information inputs.

Relevance: Notification content and addresses must be validated to prevent injection or misrouting. Protects integrity of notifications.

Integration Tips: Validate email/phone formats and sanitize message content before enqueue. Reject invalid payloads at API boundary.

Verification Method: Input validation tests and code review of notification payload handling.

Priority: High

ISO 27001:2022 Controls

A.12.4.3

Requirement: Administrator and operator activities shall be logged and the logs protected and regularly reviewed.

Relevance: Admin-triggered notifications (e.g., moderation decisions) must be logged and reviewed. Supports accountability.

Integration Tips: Restrict access to logs, enable integrity protection, and schedule reviews of admin activity related to notifications.

Verification Method: Access control check on log store and evidence of periodic reviews.

Priority: Low

6.2.12. REQ-12: Administrator and moderator dashboard for content, user and role management

OWASP ASVS Controls

V4.1.3

Requirement: Verify that administrative interfaces are protected with strong authentication and enforced least privilege.

Relevance: Admin and moderator dashboards require stronger protections due to high impact. Enforces least privilege on powerful actions.

Integration Tips: Require MFA for admin accounts, isolate admin UI, and implement fine-grained roles for moderation vs admin tasks.

Verification Method: Check admin auth configuration, MFA enforcement, and role matrix.

Level: L2 | Priority: Critical

NIST SP 800-53 Controls

AC-5

Requirement: Separate duties of individuals to reduce the risk of malevolent activity without collusion.

Relevance: Separates moderating content from managing roles/users to reduce risk. Prevents concentration of power.

Integration Tips: Create distinct roles and workflows requiring dual control for sensitive changes. Log approvals and changes.

Verification Method: Review role definitions and evidence of dual-control workflows.

Priority: High

AU-12

Requirement: Provide audit record generation capability for defined auditable events within the system.

Relevance: Admin dashboards must generate detailed audit records for actions on users and roles. Supports traceability.

Integration Tips: Instrument all admin actions to emit auditable events and centralize logs. Protect logs from tampering.

Verification Method: Audit event catalog review and sampling of admin action logs.

Priority: High

ISO 27001:2022 Controls

A.9.2.6

Requirement: The access rights of all employees and external party users to information and information processing facilities shall be removed upon termination or adjusted upon change.

Relevance: Ensures timely adjustment of admin/moderator access when roles change. Reduces insider risk.

Integration Tips: Automate deprovisioning and role adjustments through IAM; tie to HR events. Periodic access reviews.

Verification Method: Access recertification records and deprovisioning audit trails.

Priority: Medium

6.2.13. REQ-13: Reporting and abuse-flagging system with dispute handling

OWASP ASVS Controls

V7.2.1

Requirement: Verify that logs are protected from unauthorized access, tampering, and deletion.

Relevance: Abuse reports may be evidence; logs must be protected to maintain integrity for dispute handling.

Integration Tips: Use append-only log storage and restrict administrative access. Enable integrity checks and alerts on modifications.

Verification Method: Configuration review of log storage and integrity verification mechanisms.

Level: L1 | Priority: Medium

NIST SP 800-53 Controls

IR-4

Requirement: Implement an incident handling capability for incidents that includes preparation, detection and analysis, containment, eradication, and recovery.

Relevance: Abuse reports trigger incident handling processes, including analysis and resolution. Establishes lifecycle for disputes.

Integration Tips: Define triage SLAs and playbooks for abuse categories; integrate ticketing with evidence preservation.

Verification Method: Review incident response playbooks and recent abuse case records.

Priority: High

CM-9

Requirement: Develop, document, and implement a configuration management plan for the system that addresses roles, responsibilities, and configuration control.

Relevance: Supports controlled changes to abuse handling workflows and tools, minimizing errors during disputes.

Integration Tips: Document roles and change approval for moderation/abuse tooling configuration. Track changes in version control.

Verification Method: Review CM plan and change logs for abuse tooling.

Priority: Low

ISO 27001:2022 Controls

A.16.1.5

Requirement: Information security incidents shall be responded to in accordance with the documented procedures.

Relevance: Requires documented procedures for reacting to abuse/disputes. Ensures consistency and compliance.

Integration Tips: Create procedures covering intake, investigation, user communication, and closure. Train staff and log actions.

Verification Method: Procedure review and training records; audit of closed dispute tickets.

Priority: High

6.2.14. REQ-14: Automated expiry handling and lifecycle enforcement for adverts

OWASP ASVS Controls

V9.4.2

Requirement: Verify that data retention and disposal for sensitive data is defined, aligned to business need and regulatory requirements.

Relevance: Adverts should expire and be purged/archived per policy to reduce data exposure. Defines lifecycle enforcement.

Integration Tips: Implement retention policies and scheduled jobs to archive or delete expired adverts; document exceptions.

Verification Method: Review retention schedules and job configurations; sample expired records.

Level: L2 | Priority: High

V2.7.1

Requirement: Verify that sessions have a defined idle timeout and absolute timeout aligned to the business risk.

Relevance: Though session-focused, timeouts exemplify lifecycle enforcement of time-bound entities. Supports consistent expiry handling patterns.

Integration Tips: Adopt similar scheduled expiration patterns for adverts as sessions: absolute end-of-life and grace periods.

Verification Method: Check timeout settings and compare with advert expiry jobs for consistency.

Level: L1 | Priority: Low

NIST SP 800-53 Controls

AU-11

Requirement: Retain audit records for an organization-defined time period to provide support for after-the-fact investigations.

Relevance: While adverts expire, related audit records must be retained appropriately for investigations. Balances lifecycle with audit needs.

Integration Tips: Separate advert content lifecycle from audit log retention; configure different retention windows and storage classes.

Verification Method: Policy review and storage configuration for differing retention periods.

Priority: Medium

6.2.15. REQ-15: Paid-tier features: priority listing, branding, analytics, subscription and one-off payments

OWASP ASVS Controls

V4.2.3

Requirement: Verify that the application enforces authorization checks for each function, especially paid or premium features.

Relevance: Critical to ensure only paying users access premium features like priority listings and branding.

Integration Tips: Gate premium endpoints on subscription status claims and re-check on each call. Include checks in background jobs as well.

Verification Method: Attempt to access premium features with non-paid accounts; review authorization middleware.

Level: L2 | Priority: Critical

V10.4.3

Requirement: Verify that business logic enforces integrity of transactions and prevents abuse such as privilege escalation or bypass of payment checks.

Relevance: Prevents users from bypassing payment or escalating privileges to gain premium features.

Integration Tips: Implement server-side verification of payment status with PSP, and integrity checks on feature flags. Log anomalies.

Verification Method: Business logic tests simulating tampering with client-side flags and stale receipts.

Level: L2 | Priority: High

NIST SP 800-53 Controls

AU-2

Requirement: Define auditable events and ensure that the information system generates audit records for those events.

Relevance: Paid feature access and changes to subscription states must be auditable for dispute resolution and fraud detection.

Integration Tips: Log subscription activations, cancellations, and premium feature access with user and transaction IDs.

Verification Method: Audit event catalog review and sampling of payment-related logs.

Priority: Medium

ISO 27001:2022 Controls

A.12.1.1

Requirement: Operating procedures shall be documented and made available to all users who need them.

Relevance: Defines procedures for subscription management, refunds, and disputes to reduce errors and fraud.

Integration Tips: Document SOPs for handling subscription changes and one-off payments; train support staff.

Verification Method: SOP review and training records.

Priority: Low

6.2.16. REQ-16: Secure payment gateway integration and payment record management

OWASP ASVS Controls

V9.2.2

Requirement: Verify that connections to external payment service providers use strong TLS and validate certificates.

Relevance: Protects payment data in transit to PSPs, preventing MITM attacks. Essential for secure gateway integration.

Integration Tips: Enforce TLS 1.2+ with certificate validation and hostname verification; consider certificate pinning for PSP endpoints.

Verification Method: TLS scan and connection tests to PSP endpoints; review client configuration.

Level: L1 | Priority: Critical

V9.3.2

Requirement: Verify that payment-related data stored is minimized and protected using strong encryption and key management.

Relevance: Minimizes and protects stored payment records, reducing PCI scope and breach impact.

Integration Tips: Avoid storing PAN; store only tokens and necessary metadata encrypted with strong KMS-managed keys. Restrict access via RBAC.

Verification Method: Data inventory and storage encryption configuration review; access audit.

Level: L2 | Priority: High

NIST SP 800-53 Controls

SA-9

Requirement: Require that providers of external information system services comply with organizational information security requirements.

Relevance: Mandates that the PSP meets security requirements, aligning integration with organizational policies.

Integration Tips: Assess PSP security posture and include compliance reporting requirements. Monitor PSP changes impacting security.

Verification Method: Third-party risk assessment records and periodic reassessment reports.

Priority: Medium

ISO 27001:2022 Controls

A.15.1.1

Requirement: Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets shall be agreed with the supplier and documented.

Relevance: Covers contractual and security requirements with payment gateway providers. Ensures third-party compliance.

Integration Tips: Define SLAs, security clauses, breach notification, and data protection requirements with the PSP. Review SOC/PCI reports.

Verification Method: Supplier agreement review and third-party assurance evidence.

Priority: Medium

6.2.17. REQ-17: Logging, audit trails, and analytics for moderation, payments and admin actions

OWASP ASVS Controls

V7.1.3

Requirement: Verify that logs are generated for administrative actions, access control events, and security-relevant events.

Relevance: Directly addresses logging of admin actions, payments, and moderation as security-relevant events.

Integration Tips: Adopt structured logging with unique IDs; centralize logs in a SIEM; ensure clocks are synchronized.

Verification Method: Log sampling and SIEM ingestion verification for all target event types.

Level: L1 | Priority: Critical

NIST SP 800-53 Controls

AU-8

Requirement: Use internal system clocks to generate time stamps for audit records with sufficient granularity to meet system requirements.

Relevance: Accurate timestamps are vital for correlating events across moderation and payment systems.

Integration Tips: Enable NTP across services and include timezone and precision in logs. Use consistent time formats (e.g., RFC3339).

Verification Method: Check NTP configuration and compare timestamps across services.

Priority: High

AU-9

Requirement: Protect audit information and audit tools from unauthorized access, modification, and deletion.

Relevance: Ensures audit data and tooling cannot be tampered with by admins or attackers. Critical for trustworthiness.

Integration Tips: Separate duties for log management; restrict and monitor access to SIEM and log pipelines.

Verification Method: Access review for log tools and attempted unauthorized modification test.

Priority: High

ISO 27001:2022 Controls

A.12.4.2

Requirement: Logging facilities and log information shall be protected against tampering and unauthorized access.

Relevance: Protects audit trails integrity for high-stakes areas like payments and admin actions.

Integration Tips: Use append-only storage, role-based access to logs, and cryptographic integrity verification.

Verification Method: Inspect log storage controls and integrity check outcomes.

Priority: High

6.2.19. REQ-19: Security controls: encryption in transit and at rest, RBAC, MFA option, rate limiting and anti-abuse protections

OWASP ASVS Controls

V9.1.2

Requirement: Verify that all sensitive data is identified and classified, and appropriate protections are applied.

Relevance: Data classification is prerequisite to applying correct encryption at rest/in transit and access controls.

Integration Tips: Create a data classification inventory and map protections (TLS, encryption at rest, access policies) per class.

Verification Method: Review data inventory and control mappings to classification levels.

Level: L1 | Priority: Critical

V2.7.5

Requirement: Verify that session management and authentication support multi-factor authentication where appropriate.

Relevance: Satisfies MFA option requirement to harden authentication. Reduces account takeover risk.

Integration Tips: Offer TOTP/WebAuthn MFA and provide recovery mechanisms; enforce MFA for high-privilege roles.

Verification Method: Test MFA enrollment and enforcement; review auth configuration.

Level: L2 | Priority: High

NIST SP 800-53 Controls

SC-12

Requirement: Establish and manage cryptographic keys for required cryptography employed within the information system.

Relevance: Proper key management underpins encryption at rest and in transit. Prevents compromise of protected data.

Integration Tips: Use managed KMS/HSM for key lifecycle, rotation, and access controls; enforce separation of duties for key admins.

Verification Method: Key management policy review and evidence of key rotation/audit logs.

Priority: High

SI-10

Requirement: Check the validity of information inputs.

Relevance: Input validation is fundamental to anti-abuse; combined with rate limiting prevents injection and resource abuse.

Integration Tips: Apply centralized validation schemas and integrate with rate-limiting middleware at gateway level.

Verification Method: Code review of validation and gateway configs; fuzz testing of endpoints.

Priority: Medium

6.2.20. REQ-20: Accessibility and mobile responsiveness (WCAG conformance target)

OWASP ASVS Controls

V1.3.1

Requirement: Verify that security is addressed in user experience and design, including error messages and user guidance that do not leak sensitive information.

Relevance: While WCAG is accessibility-focused, secure UX ensures accessible error handling without leaking sensitive data.

Integration Tips: Design accessible error states and guidance that are clear yet do not expose internals. Include security considerations in UX reviews.

Verification Method: UX review of error messages and accessibility testing.

Level: L1 | Priority: Low

V7.3.1

Requirement: Verify that error messages are handled in a user-friendly manner without revealing sensitive information.

Relevance: Accessible applications need clear errors, but they must not expose sensitive details. This balances both goals.

Integration Tips: Return generic messages to users and detailed errors only in logs. Ensure messages meet accessibility guidelines (e.g., ARIA).

Verification Method: UI testing for error content and accessibility audits.

Level: L1 | Priority: Low

NIST SP 800-53 Controls

RA-5

Requirement: Scan for vulnerabilities in the information system and hosted applications and address identified vulnerabilities.

Relevance: Responsive frontends may introduce security flaws; ongoing scanning and remediation sustains a secure, accessible experience.

Integration Tips: Run regular dynamic scans against mobile and responsive views and triage findings promptly.

Verification Method: Scan reports and remediation tracking.

Priority: Low

ISO 27001:2022 Controls

A.14.2.1

Requirement: Rules for the development of software and systems shall be established and applied to developments within the organization.

Relevance: Secure development policies should include accessibility considerations to reduce security issues in responsive UIs.

Integration Tips: Incorporate accessibility checks into SDLC and code review policies alongside security checks.

Verification Method: Policy review and pipeline checks for accessibility/security gates.

Priority: Low

6.3. Cross-Functional Security Controls

The following controls apply globally across all system components:

Transport Layer Security

Description: Encrypt all data in transit using strong TLS and validate certificates.

Applies to: User registration and login with role assignment and secure authentication, Secure in-app messaging between users with optional verified contact reveal, Secure payment gateway integration and payment record management, Notifications system for adverts, messages and moderation status, Interactive map with clustering and approximate location display

Implementation Guidance: Enforce TLS 1.2+ with modern ciphers, HSTS, and certificate validation/pinning where appropriate.

Centralized Authorization (RBAC/ABAC)

Description: Consistent server-side authorization for all protected resources and operations.

Applies to: User registration and login with role assignment and secure authentication, Email domain verification and tier-based access controls (free vs paid advertisers), Advert creation, edit, delete lifecycle with support for multi-room properties, Administrator and moderator dashboard for content, user and role management, Paid-tier features: priority listing, branding, analytics, subscription and one-off payments

Implementation Guidance: Use a policy engine or middleware to enforce per-request checks based on roles/attributes; deny by default.

Comprehensive Logging and Audit

Description: Generate, protect, and review logs for security-relevant events and administrative activities.

Applies to: Automated and manual moderation workflow for adverts and content, Notifications system for adverts, messages and moderation status, Administrator and moderator dashboard for content, user and role management, Logging, audit trails, and analytics for moderation, payments and admin actions, Reporting and abuse-flagging system with dispute handling

Implementation Guidance: Use structured logs with timestamps and correlation IDs; protect logs from tampering and perform regular reviews in a SIEM.

Input Validation and Output Encoding

Description: Validate all inputs and encode outputs to prevent injection and XSS.

Applies to: Advert creation, edit, delete lifecycle with support for multi-room properties, Advanced filtering, saveable searches, and alerting (instant and daily digest), Interactive map with clustering and approximate location display, Notifications system for adverts, messages and moderation status

Implementation Guidance: Adopt positive validation using schemas and perform contextual output encoding in templates and UI components.

Privacy by Design and Data Minimization

Description: Minimize collection and exposure of personal and location data and provide user controls.

Applies to: User profile management with verifiable contact display options, Geo-centric search and filtered discovery with map visualisation (approximate locations), Interactive map with clustering and approximate location display, Privacy and data protection controls (GDPR compliance, consent management, data subject requests)

Implementation Guidance: Classify data, limit retention, mask or approximate sensitive fields, and implement consent and data subject rights workflows.

6.4. Requirements Traceability Overview

This section demonstrates complete traceability from high-level requirements through threats to security controls and verification methods.

Coverage Summary: Traceability matrix contains 20 requirements. 20 requirements (100.0%) linked to threats. 17 requirements (85.0%) mapped to security controls (OWASP ASVS, NIST SP 800-53, ISO 27001). Coverage: Partial.

Sample Traceability Mappings

The following table shows traceability for high-priority requirements:

Req ID	Requirement	Threats	Security Controls	Standards	Priority	Verification
REQ-001	User registration and secure login with …	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Review access provisioning SOPs, sampling of access requests, and RBAC review records.
REQ-002	Email domain verification for free-tier …	7 threats	4 controls	ISO27001, NIST, OWASP	Critical	Review service access configurations and test unauthorized access attempts.
REQ-003	User profile management capturing displa…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Access tests for different roles and review of API authorization rules.
REQ-004	Advert lifecycle management: create, sav…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Policy review and data-layer query inspection for authorization predicates.
REQ-007	Moderator and Administrator dashboard to…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Audit event catalog review and sampling of admin action logs.
REQ-011	Favourites/bookmarks management: allow u…	8 threats	4 controls	ISO27001, NIST, OWASP	Critical	Policy review and functional testing of access restrictions.
REQ-012	Secure in-app messaging system that medi…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Review cipher suites and test integrity verification on message transport.
REQ-015	Paid-tier features: priority listing / b…	6 threats	4 controls	ISO27001, NIST, OWASP	Critical	SOP review and training records.
REQ-016	Secure payment processing via a PCI-DSS-…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	TLS scan and connection tests to PSP endpoints; review client configuration.
REQ-017	GDPR-compliant data handling: obtain exp…	10 threats	4 controls	ISO27001, NIST, OWASP	Critical	Examine consent records and test withdrawal propagation to processing systems.

Showing 10 of 20 requirements. See Appendix D for complete traceability matrix.

Traceability Statistics

Total Requirements Tracked: 20
Requirements Linked to Threats: 20 (100.0%)
Requirements Mapped to Controls: 17 (85.0%)
Average Controls per Requirement: 3.4
Control Distribution by Standard:
- OWASP ASVS: 30 controls
- NIST SP 800-53: 21 controls
- ISO 27001: 17 controls
Verification Coverage: 100% (all requirements have verification methods)

7. AI/ML Security Requirements

This section addresses security requirements specific to artificial intelligence and machine learning components within the system. AI/ML systems introduce unique security challenges including prompt injection attacks, data poisoning, model theft, adversarial inputs, and bias vulnerabilities. This analysis identifies AI/ML components, assesses their security risks, and prescribes specialized controls to protect both the AI systems themselves and the data they process.

7.1. AI/ML Components Detected

This section identifies all AI/ML components within the system that require specialized security controls.
1. Automated Moderation System: AI-powered system for detecting spam and malicious content in adverts before publication.
2. In-app Messaging System: Potential use of natural language processing to enhance user communication and support.
3. Search and Filtering Mechanism: AI algorithms to improve geo-centric search results and personalized suggestions based on user behavior.

7.2. AI/ML Threat Model

Component	Identified Threats
Automated Moderation System	- Prompt injection - Data leakage - Adversarial inputs
In-app Messaging System	- Prompt injection - Data leakage - Adversarial inputs
Search and Filtering Mechanism	- Adversarial inputs - Data leakage - Bias in recommendations

7.3. AI/ML Security Controls

Automated Moderation System

Prompt Injection Prevention: Implement context-aware filtering to ensure inputs do not exploit the system.
Data Leakage Prevention: Regularly audit training data to ensure no sensitive PII is present.
Output Filtering and Sanitization: Strip sensitive or harmful information from outputs before display.

In-app Messaging System

Input Validation for AI Inputs: Validate and sanitize all messages to prevent harmful injections.
Model Access Controls: Limit access to the NLP models used for messaging to authorized personnel only.
Monitoring for Adversarial Inputs: Use anomaly detection algorithms to flag unusual patterns in messaging.

Search and Filtering Mechanism

Rate Limiting and Abuse Prevention: Implement rate limits on search queries to prevent abuse of system resources.
Monitoring for Adversarial Inputs: Regularly update the filtering algorithms to identify and mitigate adversarial manipulation of search results.
Bias and Fairness Considerations: Continuously evaluate and adjust the model to avoid biased recommendations based on user data.

7.4. Integration with Existing Security Controls

AI security controls will integrate with existing practices such as encryption, role-based access control (RBAC), and GDPR compliance measures. For instance, outputs from the AI components will be encrypted to protect sensitive data, and user roles will dictate access levels to AI functionalities, ensuring that only authorized users can modify or interact with these systems.

7.5. AI/ML Monitoring Requirements

Monitoring Area	Description
Automated Moderation System	Continuous monitoring for false positives and negatives in spam detection.
In-app Messaging System	Logging and analysis of message patterns to detect potential abuse or manipulation.
Search and Filtering Mechanism	Ongoing evaluation of search results for fairness and accuracy, along with user feedback collection.

8. Compliance Requirements

This section identifies regulatory and legal compliance obligations applicable to the system based on data types, geographic scope, industry sector, and business operations. Compliance requirements drive specific security controls, data handling procedures, audit capabilities, and privacy protections. Non-compliance can result in significant legal penalties, reputational damage, and business disruption. This analysis maps applicable regulations to specific security requirements and operational procedures.

8.1. Applicable Regulations

The identification of applicable regulations is based on the types of data processed, the geographic scope of operations, the nature of the services provided, and the industry sector involved. The platform handles personal data from users, which includes their contact information, preferences, and communication logs. Additionally, it incorporates payment processing features that are subject to financial regulations. The GDPR is particularly relevant due to the handling of personal data from EU residents, while CCPA applies to California residents. The table below outlines the specific regulations relevant to the platform’s operations.

Regulation	Applicability Reason
GDPR	The system processes personal data of EU residents, requiring compliance with data protection regulations.
CCPA	The platform collects personal information from California residents, necessitating compliance with state privacy laws.
PCI-DSS	The integration of a secure payment gateway for subscription and one-off payments involves handling payment card data.
COPPA	The platform must ensure compliance if users include minors, requiring additional protections for children’s data.
Data Residency Laws	The platform may need to comply with data residency requirements based on the geographic locations of its users.

8.2. Compliance Controls by Regulation

CCPA

Provide clear privacy notices regarding data collection and use.
Allow users to opt out of the sale of their personal information.
Implement mechanisms for users to request disclosure of their data.
Ensure appropriate training for staff handling personal data.

PCI-DSS

Encrypt cardholder data during transmission.
Maintain a secure network with firewalls and security protocols.
Restrict access to cardholder data on a need-to-know basis.
Regularly monitor and test networks for vulnerabilities.

COPPA

Obtain verifiable parental consent for users under 13.
Provide clear information about data collection practices for minors.
Implement age verification mechanisms during account creation.

Data Residency Laws

Identify data storage locations to ensure compliance with local regulations.
Implement data transfer restrictions based on jurisdictional requirements.

8.3. Data Subject Rights

Right	Description
Right to Access	Users can request access to their personal data.
Right to Rectification	Users can request corrections to inaccurate data.
Right to Erasure	Users can request deletion of their personal data.
Right to Data Portability	Users can request to receive their data in a structured format.
Right to Restrict Processing	Users can request to limit the processing of their data.

8.4. Privacy Requirements

Consent: Users must provide explicit consent for data collection, processing, and sharing.
Privacy Notice: Clear and accessible privacy notices must inform users about data handling practices.
Data Protection Impact Assessment: Conduct assessments to evaluate risks associated with data processing activities.

8.5. Audit and Monitoring Requirements

Logging: Maintain detailed logs of data access and modifications by users and administrators.
Monitoring: Regular audits to ensure compliance with security and privacy controls.
Incident Response Plan: Develop and implement a plan for responding to data breaches and security incidents.

8.6. Data Handling Rules

Retention: Data should only be retained for as long as necessary for the purposes for which it was collected.
Deletion: Implement processes for securely deleting data once it is no longer needed.
Access Controls: Limit access to personal data to authorized individuals only.

8.7. Compliance Risk Assessment

The compliance risk assessment identifies potential risks associated with failing to adhere to applicable regulations. It is essential to recognize these risks to implement effective control measures and protect user data.

Key Compliance Risks:

Non-compliance with GDPR and CCPA, leading to potential fines and legal action.
Inadequate protection of payment card data under PCI-DSS, resulting in financial loss and reputational damage.
Failure to obtain necessary consent for the collection of children’s data under COPPA, leading to legal repercussions.
Data breaches due to insufficient security measures, impacting user trust and compliance standing.

9. Security Architecture Recommendations

This section provides comprehensive security architecture guidance that integrates security controls into the system’s technical design. Security architecture defines how security principles, controls, and patterns are applied across system components to create a cohesive, defense-in-depth security posture. The recommendations address architectural principles, component-level controls, data protection strategies, and third-party integration security to ensure security is built into the system design.

9.1. Architectural Security Principles

Architectural security principles provide the foundational philosophy guiding all security design decisions. These principles ensure a consistent security posture across system components and guide the selection and implementation of controls so that the geo-centric student household vacancy platform remains resilient, privacy-preserving and compliant while usable and scalable.

Zero Trust Architecture principles: Never trust, always verify — every request (user, service, device) must be authenticated and authorized regardless of network location. This reduces implicit trust of internal networks and prevents lateral movement after compromise.
Defense in Depth: Apply multiple, independent layers of controls (network, host, application, data, identity) so that the failure of one control does not result in full compromise. Layering supports resilience and progressive detection/containment.
Principle of Least Privilege: Grant users, services and processes only the minimum permissions required to perform tasks. Minimizing privileges limits blast radius and eases auditability.
Secure by Default / Secure by Design: Build security into architecture and defaults (secure configurations, hardened images, secure libraries) so safe behavior is the natural behavior for users and operators.
Separation of Duties: Divide critical responsibilities (e.g., moderation vs role management, payments vs refunds) to reduce insider risk and require collusion for harmful actions.
Fail Secure (Fail Safe): Systems should default to a secure state on failure (deny access on policy or system failures, freeze critical actions when validation fails).
Complete Mediation: Authorize every access to a protected resource (no implicit caching of authorization decisions without re-validation when state changes).
Defense in Depth for Privacy (Privacy-by-Design): Minimize collection and retention of PII and location data; employ pseudonymization and data minimization patterns at each layer.
Secure Defaults for External Integrations: Treat every third-party dependency as untrusted; enforce strong contractual security requirements and protect secrets and traffic to/from them.
Observable and Auditable: Instrument all security-relevant events (auth, admin, moderation, payments) with structured logs, immutable audit trails and SIEM monitoring for detection and forensics.

9.2. Component-Level Security Controls

Frontend User Interface

Required Controls:

Enforce Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer Policy, and secure SameSite cookies.
Protect against XSS, CSRF and clickjacking with input sanitization and CSRF tokens.
Enforce client-side validation only as UX convenience; rely on server-side validation for enforcement.
Avoid embedding secrets/API keys; use short-lived tokens acquired from backend.
Serve assets via CDN with WAF protections and TLS 1.3.
Protect saved searches/favourites UI with strict per-user authorization checks.

Recommended Patterns:

SPA served from CDN + WAF with edge security rules.
OAuth2/OIDC flows for session management (authorization code + PKCE for public clients).
Strict separation of UI and API surface; API calls go to API Gateway.
Use safe templating libraries and sanitize map/pop-up content.
Implement offline-safe data stores (IndexedDB) with careful encryption of anything sensitive.

Edge Layer (CDN / WAF / API Gateway)

Required Controls:

Global TLS termination with TLS 1.3, HSTS and strong cipher suites.
WAF rules for OWASP Top 10 protections, bot management and IP reputation blocking.
API Gateway enforcing authentication, rate limits, quotas, and per-API authorization (tier checks).
Request/response validation, schema enforcement and size limits at the gateway.
IP reputation blocking and geo-restriction support where relevant.

Recommended Patterns:

API Gateway with OAuth2 introspection/JWT validation and per-route policies.
Edge caching for public assets; dynamic content routed to backend.
Rate limiting (per-API, per-user, per-IP) and dynamic throttling.
Use edge WAF + CDN for DDoS mitigation and caching; integrate WAF alerts into SIEM.

Application Services

Required Controls:

Centralized authentication and authorization (RBAC/ABAC) enforced per-request.
Mutual TLS or service-to-service authentication (mTLS or strong mTLS alternatives) inside the platform.
Input validation and output encoding at service boundaries.
Secure secrets handling (secrets manager / vault) and parameterized DB queries to prevent injection.
Service-level logging with correlation IDs; redact PII in logs.
Circuit-breakers, throttling, idempotency for message handling.
Hardened container or server images with vulnerability scanning.

Recommended Patterns:

API Gateway in front of microservices; microservices behind a service mesh (mTLS, observability).
Policy engine for attribute-based access controls (e.g., OPA/Rego).
Messaging via durable queues (SQS/Kafka) with encryption-at-rest and access control.
Use multi-tenant aware services with scoped keys for user records and adverts.

Data Storage

Required Controls:

Encrypt all data at rest using strong algorithms (TDE for RDBMS + column-level encryption for PII).
Row/column-level access controls for PII and adverts metadata.
Database access only from application subnets and via least-privileged DB roles.
Secure object storage for media with signed short-lived URLs and content scanning (malware, PII detection).
Harden backups and snapshots (encrypted, stored in separate account/region, immutable storage where required).

Recommended Patterns:

Encrypted RDBMS with Transparent Data Encryption (TDE) + column encryption for PII.
Use search index (Elasticsearch/OpenSearch) in private VPC, pre-processed and stripped of exact coordinates/PII.
Object storage (S3/GCS/Azure Blob) with per-object KMS encryption and lifecycle policies.
Use Data Access layer that enforces owner scoping and ABAC predicates.

External Services

Required Controls:

Store API credentials in secrets manager and rotate regularly.
Use minimal privilege scopes for service accounts/APIs.
Verify TLS certificates, enable certificate pinning where possible and validate webhook signatures.

Recommended Patterns:

Controlled egress via NAT gateways and allowlists; centralized outbound proxy for HTTP(s) with logging.
Use signed webhooks with HMAC verification and replay protections.
Integrate third-party SDKs with explicit review and limit scope in CSP.

Admin & Moderation

Required Controls:

Admin UI protected by SSO with mandatory MFA for admin/moderator roles.
Role separation: distinct moderator and administrator roles, with dual-control for destructive actions.
JIT (Just-in-Time) and step-up authentication for sensitive actions.
Full audit logging for all admin and moderation actions, immutable storage and SIEM alerting.

Recommended Patterns:

Isolated admin network / bastion hosts and conditional access policies (IP allowlists, client certs).
Use privileged access management (PAM) for elevated actions.
Workflow-based moderation queue with evidence preservation and versioned actions.

Notifications & Messaging

Required Controls:

TLS 1.3 for API/Websocket connections and delivery channels where applicable.
Messages encrypted at rest; retention and redaction rules applied for PII.
Content scanning and sanitization for message text to remove malware and PII before delivery.
Rate limiting and anti-automation controls for outgoing notifications.

Recommended Patterns:

Mediated messaging model (no direct user contact unless verified + step-up).
Use queueing system (SQS/Kafka) and worker pools with backpressure handling.
Template engines with contextual encoding for email and push (no raw HTML from users).

Payments & Billing

Required Controls:

No storage of PAN; use PSP tokenization and maintain PCI-compliant integration patterns.
Enforce TLS, certificate validation and strong authentication for payment operations.
Logging of payment events with strict access control and separation of logs vs transaction payloads.

Recommended Patterns:

Redirect / hosted payment page or tokenization via client-side PSP SDKs to minimize PCI scope.
Server-side verification of payment status via PSP webhooks with signed payloads.
Payment gateway integration through isolated environments and role-limited service accounts.

9.3. Data Protection Strategy

Data Classification: Public, Internal, Confidential, Restricted

Public: Aggregated non-identifying adverts metadata, neighbourhood heatmaps (no PII or exact coords).
Internal: System telemetry, anonymized analytics, non-sensitive application metadata.
Confidential: User profile PII (name, email, phone when verified), messaging contents, billing metadata (excluding PAN tokens), saved searches/favourites.
Restricted: Exact addresses (if stored by consent), payment PAN (should never be stored), verification documents (IDs), and admin audit logs that could be used for abuse or identity theft.

Encryption Requirements:

Data in transit: TLS 1.3 mandatory for all external and internal HTTP(s) endpoints; HSTS for web. Use mutual TLS for service-to-service where practical.
Data at rest (databases / object storage):
- Use AES-256-GCM for envelope/data key encryption (AES-256 with GCM for authenticated encryption).
- Use KMS/HSM-backed Customer Master Keys (CMKs) with envelope encryption for data keys.
- Column-level encryption for high-risk fields (e.g., user contact details, identity docs) with AEAD.
Passwords:
- Store using Argon2id (recommended parameters: memory ~64MB-256MB, iterations >=3, parallelism 1-4 depending on load) or bcrypt with strong parameters if Argon2 not available.
Asymmetric crypto:
- Use ECDSA or ECDH with curve P-256 or P-384 for signatures and key exchange; RSA-3072+ if RSA used.
Key lifetimes & rotation:
- Data keys rotated every 90 days; CMKs rotated yearly or per policy.
- Enable automatic KMS key rotation and maintain key access logs.
Logging & backups:
- Ensure audit logs are encrypted with separate keys and stored in append-only or WORM storage.

Retention Policies:

Adverts (active): retain until expiry + configurable grace period (default 90 days) then archive for investigation for a minimal period (e.g., 12 months) before secure deletion unless legal reasons require longer retention.
Expired/Deleted adverts: soft-delete immediately; physical deletion or shredding from primary store after retention period. Keep audit records for a longer period (e.g., 2–7 years depending on legal/compliance).
Messaging: retain for business needs with a default of 180 days for in-app messages, configurable by admin policy; redact/delete on DSAR or upon user deletion subject to moderation evidence preservation needs.
Payment metadata: keep transaction metadata for tax and invoicing per local law (typically 7 years for many jurisdictions) but do not store PAN. Store PSP tokens and minimal metadata.
Logs & audit trails: security logs retained in SIEM per organizational policy (e.g., 1 year hot storage, 3–7 years cold archival) and protected from tampering.
Verification documents: retain only as long as necessary for verification, default 12 months, unless required to retain longer by law.

Handling Procedures:

Access:
- Enforce RBAC/ABAC for all data access; require least privilege for operators.
- Admin access to PII requires MFA and justifications recorded; use break-glass with approvals.
Transmission:
- All transmissions over TLS 1.3+; use signed authentication tokens (JWTs with short TTLs) and refresh patterns.
- For third-party calls, use mTLS where available or strict TLS with certificate validation and allowlist endpoints.
Storage:
- Use envelope encryption with KMS for objects and database fields. Apply separation of keys for different environments (prod/test).
- Search index must not contain raw PII or exact coordinates; include pseudonymized IDs and approximate geohash.
Deletion:
- Implement deterministic deletion workflows: soft-delete flag, then scheduled purge jobs. Ensure backups retention policies are aligned and that purges also remove data from backups per policy constraints.
Data Subject Requests (DSAR):
- Maintain ROPA and consent store; implement automated DSAR exports and erasure workflows that cascade to search indexes, caches, third-parties where feasible and log all actions.
Pseudonymization & Approximation:
- Store approximate location (coarse geohash / grid cell) for all public exposures. Exact coordinates, if ever needed, must be separately encrypted and access-controlled and only accessible with explicit consent and justification.
Monitoring & Alerting:
- Monitor access patterns to PII and generate alerts for anomalous access (unusual volumes, admin access outside business hours, bulk exports).
Test Data:
- Prohibit use of live PII in non-prod. Provide synthetic or anonymized datasets for development/testing.

9.4. Third-Party Integration Security

Mapbox / Google Maps (Maps API)

Security Requirements:

Use API keys stored in a secrets manager, not hard-coded.
Enforce usage restrictions (HTTP referrer restrictions, domain allowlists).
Use TLS for all API calls.
Validate and monitor requests/quotas.

Risk Assessment: High — map APIs are needed for geo visualisation; leak of exact coordinates or misuse of keys can reveal sensitive location metadata or run up costs.

Recommended Controls:

Enable domain/referrer and IP restrictions on API keys.
Route third-party map calls through a controlled backend or egress proxy to avoid exposing keys to clients (or use short-lived tokens).
Limit map responses to coarse location; avoid storing raw tile metadata containing precise coordinates.
Monitor API usage, set quotas and alert on anomalies.

SendGrid / Mailgun or similar (Email Service Provider)

Security Requirements:

Store API keys in secrets manager with rotation.
Use TLS for SMTP/API.
Verify webhook signatures and use authenticated webhook endpoints.

Risk Assessment: High — email channel can be abused for spam/phishing and leaks of PII. Misconfigured templates could allow injection/XSS.

Recommended Controls:

Enforce templating that encodes user-provided content.
Apply rate limits for triggered emails and digest generation.
Monitor bounce/spam rates and reputation; implement DKIM, SPF, DMARC.
Validate webhooks via signature verification.

Firebase Cloud Messaging (FCM) / APNs (Push Providers)

Security Requirements:

Secure service credentials in vault; use per-environment credentials.
Use TLS for push provider connections.

Risk Assessment: Medium — push notifications may leak content if not sanitized and can be abused to spam devices.

Recommended Controls:

Throttle push notification sends and use user opt-in.
Avoid sending PII in push payloads; link into the app that requires authentication to view content.
Monitor push failures and detect unusual volumes.

Stripe / Adyen / Payment Gateway

Security Requirements:

PCI-DSS compliant integration; never store PAN.
Use tokenization for cards and TLS for all payment interactions.
Validate webhook signatures.

Risk Assessment: Critical — financial data and billing operations; risk of fraud and regulatory exposure.

Recommended Controls:

Use hosted payment pages or client-side tokenization (PSP SDK).
Restrict webhooks to endpoint allowlisted IPs and signed payloads.
Maintain contractually required assurances (PCI Attestation, SOC reports).
Perform reconciliation and fraud monitoring; log payment events in immutable audit logs.

CDN / WAF Provider (Cloudflare/Akamai/etc.)

Security Requirements:

Secure account with SSO + MFA for admin roles.
Use WAF rulesets, bot mitigation and DDoS protections.

Risk Assessment: High — if compromised, it can affect content integrity and traffic flow.

Recommended Controls:

Enable least-privileged admin roles and IP-restricted dashboard access.
Configure WAF rules tuned to application behavior and OWASP protections.
Use encryption (TLS), origin attestation (client certs to origin) and private network peering where possible.

Elasticsearch / OpenSearch (Search Index)

Security Requirements:

Restrict access to private VPC; require authentication and TLS.
Do not store raw PII or exact coordinates in the index.

Risk Assessment: High — search clusters have had high-profile exposures; unprotected clusters leak sensitive data.

Recommended Controls:

Network isolation (VPC), IP allowlists and IAM-based access controls.
Enable node-to-node TLS, authentication (e.g., native auth or proxy), encryption at rest.
Index only pseudonymized IDs and coarse geohashes; implement scrubber jobs to remove PII.

ML Moderation Tooling (Third-party / SaaS)

Security Requirements:

Clear data sharing contract and DPIA for sending content to third-party moderation services.
Prefer on-prem or private VPC deployment for sensitive content.

Risk Assessment: Medium to High — content may include PII or sensitive images; sharing increases privacy risk and regulatory obligations.

Recommended Controls:

Use privacy-preserving techniques (hashing, tokenization, on-device or on-prem inference where possible).
Log and monitor what content is sent, keep minimal context, and maintain consent/DSAR ability.
Contractual safeguards: data processing addendum, breach notification SLAs, deletion policies.

Identity Provider (SSO / Okta / Azure AD / Auth0)

Security Requirements:

Use OIDC/OAuth2 and enforce MFA for privileged roles.
Configure role/claim mappings and enforce SCIM for provisioning.

Risk Assessment: High — identity provider compromise leads to broad access.

Recommended Controls:

Enforce SSO with short session TTLs and conditional access (IP, device posture).
Monitor for suspicious sign-ins, enforce risk-based authentication and device postures.
Use just-in-time provisioning with automated de-provisioning on off-boarding.

Email/Push Webhooks and Notification Providers

Security Requirements:

Validate signatures for all incoming webhooks.
Restrict endpoints to provider IP ranges where available.

Risk Assessment: Medium — unauthenticated webhooks enable spoofing and fraudulent state changes.

Recommended Controls:

Use HMAC signatures, timestamp checks and replay protection.
Log webhook deliveries and failures and correlate with payment/notification events.

Analytics / Timeseries Tools (Datadog / New Relic)

Security Requirements:

Do not send raw PII to analytics providers.
Use secure API keys in secrets manager and limit dashboard access.

Risk Assessment: Medium — leakage of PII into analytics can create compliance risk.

Recommended Controls:

Scrub PII before sending; use pseudonymized identifiers.
Restrict analytics dashboards to authorized auditors and admins.

Concluding notes (how elements work together):

Enforce identity-first control at every layer: edge validates token → gateway enforces RBAC/ABAC policies → services re-check ownership and apply data scoping. This implements Zero Trust and Complete Mediation.
Encryption and key management are foundational: KMS-backed envelope encryption protects PII/keys across storage, backups, and logs.
Privacy-by-design is enforced via approximate geolocation (coarse geohashes/grids) at ingestion and strict redaction of exact coordinates from search indexes, logs and map payloads.
Monitoring and response: central SIEM and alerting should aggregate auth, admin, moderation, payment and data-access events; automated playbooks (IR-4) drive triage for abuse and DSAR handling.
Third-party integrations are treated as untrusted endpoints with contractual, technical and operational mitigations (mTLS, webhooks signatures, tokenization, minimal scopes and rigorous logging).
Operational security: include deployment pipelines with SCA/DAST, periodic penetration testing, vulnerability management and privileged access management for administrators.

This architecture and controls mapping meets the REQ-* mappings and ASVS L2 recommendations and will enable a secure, privacy-preserving student household vacancy platform when implemented under governed SDLC, continuous monitoring, and regular audit/review cycles.

10. Implementation Roadmap

This section provides a prioritized, phased approach for implementing the security controls identified throughout this analysis. The roadmap organizes security measures into logical phases based on risk, dependencies, and resource availability, ensuring critical security gaps are addressed first while building a foundation for comprehensive security coverage.

10.1. Prioritization Framework

Prioritization is essential for effectively implementing security controls within the constraints of time, resources, and business operations. By organizing security controls into phases, we can address the most critical risks first, ensure compliance with regulatory requirements, and lay the groundwork for future enhancements. The following criteria guide our prioritization:

Prioritization Criteria:

Risk Level: Controls addressing critical and high-risk threats (identified through threat modeling) are prioritized first
Compliance Deadlines: Regulatory requirements and compliance deadlines influence immediate priority
Technical Complexity: Controls requiring foundational infrastructure are implemented early to enable subsequent controls
Dependencies: Controls that other security measures depend upon are prioritized accordingly
Resource Availability: Implementation considers the availability of skilled personnel, tools, and budget
Business Impact: Controls protecting business-critical functions and data receive higher priority

These criteria work in concert to create a logical implementation sequence that balances security needs with practical constraints, ensuring that urgent security gaps are closed swiftly while setting the stage for comprehensive, long-term improvements.

10.2. Phased Implementation Plan

Phase: IMMEDIATE

Timeline: 0-1 months
Rationale: This phase addresses the most critical vulnerabilities and compliance blockers that pose immediate risks to the platform’s security and regulatory standing.
Controls to Implement: - Implement robust password handling and secure authentication mechanisms - Establish role-based access control (RBAC) for all protected resources - Encrypt sensitive data in transit using TLS 1.2+ - Implement logging for security-relevant events - Ensure GDPR and PCI-DSS compliance by addressing blockers Dependencies: - None

Phase: SHORT-TERM

Timeline: 1-3 months
Rationale: These controls build upon immediate security measures, focusing on improving access control adjustments and ensuring that logging and API security mitigate identified threats effectively.
Controls to Implement: - Enhance user authentication through comprehensive multi-factor authentication - Deploy role-based access controls across the admin dashboard - Implement comprehensive logging and monitoring for all administrative actions - Strengthen API security with input validation and HTTPS protocols - Begin encryption for all sensitive data at rest Dependencies: - Completion of TLS Implementation - Completion of multi-factor authentication

Phase: MEDIUM-TERM

Timeline: 3-6 months
Rationale: This phase focuses on implementing advanced security measures and enhancing data protection strategies that require more planning and integration.
Controls to Implement: - Deploy advanced threat detection and response capabilities - Automate security testing and integrate into CI/CD pipelines - Conduct third-party security audits and assessments - Enhance data protection with field-level encryption and geo-obfuscation Dependencies: - Completion of enhanced authentication and access controls

Phase: LONG-TERM

Timeline: 6-12 months
Rationale: Strategic initiatives aimed at achieving long-term security maturity and integrating cutting-edge technologies for continuous improvement.
Controls to Implement: - Develop a comprehensive security awareness and training program - Integrate AI/ML-based security controls for proactive threat detection - Conduct comprehensive penetration testing and red team exercises - Establish a robust incident response readiness program Dependencies: - Completion of advanced threat detection and security testing automation

Phase: ONGOING

Timeline: Continuous
Rationale: These activities ensure the platform maintains a strong security posture and responds effectively to new threats and compliance requirements.
Controls to Implement: - Continuous security monitoring and threat intelligence - Regular patch management and vulnerability remediation - Compliance audits and regulatory updates - Incident response and recovery exercises Dependencies: - Ongoing updates to security and compliance frameworks

10.3. Resource Requirements

Skills: Security engineers, Security architects, Web developers, Compliance specialists; Recommended tools: SIEM solutions for logging and monitoring, Vulnerability scanners for testing, Encryption libraries for data protection, API management tools for secure interfaces; Estimated time effort: Approximately 3-6 months for initial phases, with ongoing efforts extending resources as per system complexity and requirements.

11. Verification and Testing Strategy

11.1. Testing Approach

Integrate security testing throughout the software development lifecycle (SDLC) with an emphasis on continuous security practices. Balance automated scanning with manual evaluations to prioritize high-risk areas based on business impact, adhering to shift-left security principles by incorporating security testing earlier and continuously. This approach ensures that vulnerabilities are identified and resolved before they reach production, reducing overall risk and improving compliance with regulations.

11.2. Testing Methods

Method	Frequency	Tools
STATIC APPLICATION SECURITY TESTING (SAST)	Every commit/build	SonarQube, Semgrep, Checkmarx, CodeQL
DYNAMIC APPLICATION SECURITY TESTING (DAST)	Nightly/weekly	OWASP ZAP, Burp Suite, Acunetix
DEPENDENCY SCANNING	Every build	Snyk, Dependabot, OWASP Dependency-Check
SECRETS SCANNING	Every commit	TruffleHog, GitLeaks, GitHub Secret Scanning
CONTAINER/INFRASTRUCTURE SCANNING	Every deployment	Trivy, Clair, Prowler, ScoutSuite
PENETRATION TESTING	Quarterly or before major releases	Custom scripts, Metasploit, Burp Suite Pro
SECURITY CODE REVIEW	For critical features	GitHub/GitLab code review, security checklists
COMPLIANCE SCANNING	Continuous	AWS Config, Azure Policy, Cloud Custodian

11.3. Compliance Verification

Multi-standard compliance (OWASP ASVS, NIST SP 800-53, ISO 27001) will be verified through automated tools and manual checks against regulatory requirements such as GDPR, CCPA, and PCI-DSS. Audit preparation will involve ensuring documentation and evidence collection for external audits, including logs, assessments, and compliance checklists. Recommendations will include engaging third-party auditors for comprehensive evaluations to verify adherence to all applicable legislation and best practices.

11.4. Continuous Monitoring

Implement Security Information and Event Management (SIEM) for real-time monitoring, supported by Intrusion Detection/Prevention Systems (IDS/IPS) to identify and mitigate threats. All logs will be aggregated and analyzed for anomalies, with integration into incident response processes to ensure prompt action against security events. This will facilitate continuous threat assessment and improve the organization’s ability to respond to incidents effectively.

11.5. Key Performance Indicators (KPIs)

Mean time to detect (MTTD) security issues
Mean time to remediate (MTTR) vulnerabilities
Percentage of critical vulnerabilities patched within SLA
Security test coverage percentage
False positive rate in automated scanning
Compliance audit pass rate

11.6. Mapping Testing Methods to Security Controls

Testing Method	Security Controls (OWASP ASVS, NIST SP 800-53, ISO 27001) Verified
STATIC APPLICATION SECURITY TESTING (SAST)	Input validation, authentication, authorization, cryptographic protections, hardcoded secrets
DYNAMIC APPLICATION SECURITY TESTING (DAST)	Authentication, authorization, XSS, CSRF, SQL injection, session management
DEPENDENCY SCANNING	Supply chain security, vulnerability management
SECRETS SCANNING	Cryptographic protection, secrets management
CONTAINER/INFRASTRUCTURE SCANNING	Configuration management, infrastructure security
PENETRATION TESTING	All high-risk controls, business logic integrity
SECURITY CODE REVIEW	Authentication, authorization, cryptographic implementations, data protection
COMPLIANCE SCANNING	All compliance-related controls, auditing, access controls

This comprehensive security verification and testing strategy is designed to ensure a robust security posture throughout the software development lifecycle and maintain compliance with applicable regulations.

12. Validation Report

This section presents a comprehensive validation of the security requirements generated throughout this analysis. The validation evaluates the requirements against five key dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. This assessment ensures that the security requirements are comprehensive, technically sound, and actionable for implementation teams.

12.1. Overall Assessment

The overall validation score reflects the quality and completeness of the security requirements across five critical dimensions. Each dimension is scored from 0.0 to 1.0, with 1.0 representing excellent coverage and 0.0 indicating significant gaps.

Overall Score: 0.88/1.0

Validation Status: ✅ PASSED

The security requirements have met the quality threshold (≥0.8) and are ready for implementation. The requirements demonstrate comprehensive coverage, technical accuracy, and alignment with business objectives.

The validation assesses:

Completeness: Are all identified security concerns adequately addressed?
Consistency: Do requirements align with each other without contradictions?
Correctness: Are controls appropriate for the identified risks and correctly applied?
Implementability: Are requirements specific, actionable, and feasible to implement?
Alignment: Do security requirements align with business requirements and objectives?

12.2. Dimension Scores

Dimension	Score	Status
Completeness	0.80	✅
Consistency	0.95	✅
Correctness	0.90	✅
Implementability	0.80	✅
Alignment	0.95	✅

Score Interpretation: - ✅ 0.8-1.0: Excellent - ⚠️ 0.7-0.79: Acceptable (minor improvements needed) - ❌ <0.7: Needs significant improvement

12.3. Detailed Feedback

Summary The provided security requirements and control mappings give strong, broad coverage across authentication, authorization, privacy, moderation, geo-privacy, payments, logging, and AI/ML concerns. They align well with the business needs for a geo-centric student-housing platform and map to appropriate standards (OWASP, NIST, ISO27001). However, several areas need clarification, additional coverage, or more prescriptive acceptance criteria to make the requirements fully implementable and to close risk gaps. Actionable improvements (prioritised) 1) Add explicit API and web application security controls (high priority) - Specify CSRF protection, cookie policies (Secure, HttpOnly, SameSite), CORS allowlist rules, and OAuth2/OpenID Connect or SAML support if third-party SSO is required. Acceptance criteria: per-endpoint tests demonstrating CSRF tokens and cookie flags, and an SSO integration test plan. - Define API gateway responsibilities: authentication, authorization enforcement, rate limiting, request throttling, request size limits, and request/response schema validation. Acceptance criteria: gateway policies documented and automated tests proving enforcement. - Include WAF and OWASP Top 10 testing in security gates (DAST) and SAST in CI. Acceptance criteria: DAST/SAST baseline results with remediation plan and tracked CVE/issue closure. 2) Strengthen secrets, key, and credential management (high priority) - Mandate centralized KMS/HSM usage for application keys, encryption keys, and API credentials, with automated rotation policies and RBAC for key administrators. Acceptance criteria: KMS configured, rotation schedule documented and demonstrable, role separation in place. - Add guidance to avoid storing long-lived credentials on mobile devices and to use short-lived tokens with refresh-token rotation and revocation. Acceptance criteria: refresh token rotation implemented and revocation test passes. 3) Expand anti-abuse, fraud, and availability controls (high priority) - Define DoS/DDoS mitigations, WAF rules, scaling/auto-scaling plans, and rate limits by endpoint/type (search, alerts, messaging). Include abuse detection for bulk account creation and alerting pipelines. Acceptance criteria: simulated traffic tests showing graceful degradation and auto-scaling, rate-limit tests. - Add account takeover detection: anomalous login detection, device fingerprinting, IP risk scoring, and mandatory MFA for high-risk actions. Acceptance criteria: ATM detection rules and step-up authentication tests. 4) Make AI/ML governance concrete (high priority) - For the automated moderation, search ranking, and NLP components add a Model Governance control set: model cards, versioning, change control for models, training-data provenance, PII scrubbing from training sets, evaluation metrics, adversarial robustness testing, and rollback procedures. Acceptance criteria: model cards present, versioned deployments with canary rollout tests, documented training data provenance and PII removal checks. - Add continuous monitoring for model performance/drift (false positive/negative rates) and an incident playbook when models degrade. Acceptance criteria: monitoring dashboards and alert thresholds defined for drift and accuracy. 5) Improve privacy-by-design specifics for geolocation and PII (high priority) - Define the exact technique and granularity for approximate locations (e.g., grid size or geohash precision). Specify minimum aggregation thresholds for map clustering to avoid deanonymization. Acceptance criteria: tests confirming no exact coordinates are returned and that de-anonymization risk analysis passes. - Specify retention windows for adverts, messages, and logs and align them with DSAR/ROPA. Acceptance criteria: retention policy documented and deletion/archive jobs tested. 6) Make logging, monitoring, and incident response operational (high priority) - Define log retention periods, encryption of logs, append-only storage or WORM, separation of duties for log access, and SIEM alerting playbooks. Acceptance criteria: SIEM rules documented, access controls for log stores demonstrated, and sample incidents run through the playbook. - Provide incident response SLAs and escalation paths for abuse reports, data breaches, and paid-tier disputes. Acceptance criteria: playbooks and runbook drills with lessons learned. 7) Payment and PCI scope tightening (high priority) - Emphasize using PSP tokenization to keep PAN out of platform systems. Add PCI-specific requirements (SAQ or attestation) and periodic PCI scans/assessments. Acceptance criteria: no PAN stored in logs/databases, Payment flows pass PSP and PCI attestations. 8) Add supply-chain, third-party, and mobile-specific controls (medium priority) - Add supply-chain controls for third-party libraries, map providers, and NLP/ML providers (SBOM, dependency scanning, third-party risk assessment). Acceptance criteria: SBOM present and dependency scanning configured in CI. - For mobile: define secure local storage, certificate pinning (where appropriate), jailbreak/root detection, and secure update channels for mobile apps. Acceptance criteria: mobile hardening checklist and tests passing on supported device matrix. 9) Make requirements measurable and testable (medium priority) - For each control include acceptance criteria: who is owner, test method (unit/integration/pen-test), pass/fail criteria, and expected logging/metrics. Example: “MFA required for admin logins; test: attempt admin login without MFA — expected: denied; evidence: auth logs show step-up event.” 10) Improve AI/ML security specifics for prompt injection and data leakage (medium priority) - Provide concrete mitigations: input sanitization libraries, guarded prompt templates, output filters, rate limits on model queries, and data retention policies for prompts/responses. Acceptance criteria: fuzz/prompt-injection tests passing and prompt logs redaction verified. Other suggested clarifications and minor fixes - Clarify DSAR response timelines, default consent legal bases (contractual/legit interest), and how consent withdrawal is implemented (propagation latency). Add measurable SLA targets. - Explicitly state “never log sensitive fields” (e.g., full email, phone, PAN) or require redaction in logs with examples. - Add a backup & restore / disaster recovery requirement (RTO/RPO targets) especially for critical data (user profiles, payments ledger, audit logs). - Provide a mapping of high-risk endpoints to required testing cadence (SAST: weekly on CI, DAST: monthly, Pen Test: annual or after major release). - For moderation, add integrity and privacy controls for stored evidence (images, messages) and retention rules for investigation data. Why these changes matter - They close operational gaps (API security, key management, DDoS), reduce legal/compliance risk (PCI, GDPR), and make AI controls actionable and auditable. They also convert high-level guidance into developer-testable acceptance criteria so implementation and validation are practical. Recommended next steps (concrete) 1. Update requirements document to include the missing controls above and attach acceptance criteria per control. 2. Create a prioritized implementation backlog covering the high-priority items (API gateway, secrets/KMS, model governance, CSRF/cookie policy, DDoS and rate-limits, PCI tokenization). 3. Define owners for each control and a verification plan (unit/integration tests, SIEM rules, pen tests) with timelines. 4. Run a threat-modeling workshop focused on geo-deanonymization and ML adversarial threats and update controls accordingly. 5. Deliver a compliance mapping artifact that ties each control to GDPR/PCI/CCPA/COPPA obligations and evidence required for audits. If you want, I can produce: (a) a prioritized backlog of the specific changes with user stories and acceptance criteria; (b) example test cases for the highest-risk controls (API gateway, MFA, KMS, ML governance); or (c) a concrete geolocation anonymization spec (grid size recommendations and deanonymization analysis).

Appendix A: Original Requirements Document

Student Household Vacancy Platform Requirements

We need to build a geo-centric platform for advertising and discovering vacancies in student households (sharehouses) and for finding potential housemates. The system will prioritise location-based information while ensuring user security and privacy.
Key Features:

1. User Management

Account creation and secure login.
User profiles with role assignments (Advertiser, Seeker, Moderator, Administrator).
Email domain filtering for free-tier advertisers (e.g., only university email addresses).
Paid-tier access for agencies, hostels, and temporary accommodation providers.

2. Advert Management

Submit, edit, and delete adverts for properties and rooms.
Each property can include multiple rooms with individual details (cost, size, availability).
Automatic filtering and moderation system to detect spam and malicious content before publication.
Adverts are not immediately active; require approval by moderators or automated checks.
Rich advert details including:

Location (approximate, not exact address for security).
Room specifications (size, furnishings, amenities, cost, deposit).
Household preferences (smoking, pets, occupation, age range, language, vegetarian preference).
Availability dates and minimum/maximum stay.
Bills and broadband inclusion.

3. Search and Filtering

Geo-centric search with approximate location visualisation (e.g., neighbourhood or postcode area).
Advanced filters: price range, distance from a specific point, number of housemates, amenities, stay duration.
Ability to save filter sets and searches.
Email alerts for new adverts matching saved criteria (daily digest and instant notifications).

4. Favourites and Personalisation

Users can “favourite” properties or rooms.
Generate a personalised summary list of saved adverts.
Option to manage and organise favourites within the user dashboard.

5. Collaboration and Communication

Secure in-app messaging between advertisers and seekers.
No direct contact details displayed publicly; communication mediated through the platform.
Optional display of phone number/email for verified users.


6. Visualisation

Interactive map showing approximate locations of properties.
Clustered view for areas with multiple adverts.
No exact addresses displayed, only general vicinity, for general safety of advertises.

7. Notifications

Email notifications for saved searches and favourites.
In-app notifications for advert status changes (approved, expired, updated).
Alerts for messages and responses.

8. Control System

Administrator and moderator dashboard for:

- Approving, disabling, or deleting adverts.
- Managing user accounts and roles.
- Reviewing flagged content and handling disputes.

Automated moderation tools for detecting inappropriate content and spam.
Reporting system for users to flag suspicious adverts.
Automatically remove expired adds.

1. Paid Tier

Premium advertising options for agencies, hostels, and temporary accommodation providers.
Features for paid tier:

Priority listing and enhanced visibility.
Ability to include branding and extended descriptions.
Analytics dashboard for advert performance.
Secure payment gateway integration for subscription and one-off payments.

10. Security and Privacy

Approximate location display to protect user privacy.
Verification of email domains for free-tier advertisers.
GDPR-compliant data handling and storage.

11. Platform Accessibility:
The application will be accessible via web browser and optimised for mobile devices. It will store user data, advert details, location metadata, and communication logs securely.

Appendix B: Glossary

Term	Definition
ASVS	Application Security Verification Standard (OWASP)
STRIDE	Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege
SAST	Static Application Security Testing
DAST	Dynamic Application Security Testing
MFA	Multi-Factor Authentication
RBAC	Role-Based Access Control
PII	Personally Identifiable Information
PHI	Protected Health Information
GDPR	General Data Protection Regulation
HIPAA	Health Insurance Portability and Accountability Act
PCI-DSS	Payment Card Industry Data Security Standard

Appendix C: Complete Threat List

This appendix contains the complete list of all identified threats with full descriptions and mitigation strategies. Threats are organized by risk level for easy reference.

Critical Risk Threats

THR-001 - Frontend Layer

Category: Information Disclosure
Likelihood: High | Impact: High
Risk Level: Critical
Description: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content, favourites, or saved searches causing session token theft, account takeover, or exfiltration of PII from pages rendered in other users’ browsers.
Mitigation Strategy: Apply strict output encoding/escaping for all user content, use a secure templating engine, implement Content Security Policy (CSP) restricting script sources, sanitize HTML with a safe whitelist or disallow HTML, mark session cookies HttpOnly and SameSite=strict; conduct automated and manual security testing (SAST/DAST).

THR-006 - Application Services (Auth/RBAC)

Category: Spoofing
Likelihood: High | Impact: High
Risk Level: Critical
Description: Credential stuffing, weak password reuse, or brute-force attacks leading to account takeover for advertisers or moderators. Email domain filtering for free-tier may be bypassed using disposable or compromised university addresses.
Mitigation Strategy: Implement rate-limited login attempts, account lockouts with progressive delays, MFA (mandatory for moderators/admins and encouraged for advertisers), password strength policy, monitor for credential stuffing via IP reputation and breached-password checks; verify university domain via domain MX checks and time-limited email verification tokens.

High Risk Threats

THR-002 - Frontend Layer

Category: Tampering
Likelihood: High | Impact: Medium
Risk Level: High
Description: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, prices, or display premium features) and submitting forged requests that rely on client-side checks (price, entitlements).
Mitigation Strategy: Enforce server-side authorization and validation for all business-critical operations (price changes, entitlement checks). Sign client-visible configuration where needed, validate inputs on server, and log suspicious client-side anomalies.

THR-004 - Edge Layer (CDN/WAF/API Gateway)

Category: Denial of Service
Likelihood: Medium | Impact: High
Risk Level: High
Description: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or advert submission endpoints to degrade availability and impact revenue and user confidence.
Mitigation Strategy: Use CDN + WAF with adaptive rate-limiting and geo-blocking, API Gateway throttling per IP and per-account, autoscaling backend, CAPTCHA for suspicious flows (advert creation), traffic anomaly detection and scrubbing service.

THR-005 - Edge Layer (API Gateway)

Category: Spoofing
Likelihood: Medium | Impact: High
Risk Level: High
Description: Replay attacks or token theft in transit due to inadequate transport security or poor token handling (long-lived tokens, insecure storage on client) leading to account hijacking.
Mitigation Strategy: Enforce TLS 1.2+/HSTS, short-lived access tokens with refresh tokens stored securely, require token binding if possible, use OAuth 2.0 best practices, revoke tokens on suspicious activity, secure local storage (avoid persistent tokens in localStorage), implement device/session fingerprinting and MFA for sensitive actions.

THR-007 - Application Services (Auth/RBAC)

Category: Elevation of Privilege
Likelihood: Medium | Impact: High
Risk Level: High
Description: Broken access control allowing privilege escalation (e.g., seeker modifies request to set ‘role=moderator’ or uses API endpoints reserved for admin to approve adverts).
Mitigation Strategy: Enforce server-side RBAC checks for every sensitive endpoint, implement deny-by-default ACLs, use centralized authorization library, detailed audit logging of role changes, review admin endpoints manually and require MFA/SSO for admin actions.

THR-008 - Application Services (Core API/Search/Geo)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Risk Level: High
Description: Exposure of exact addresses or PII via search index or API responses (e.g., detailed coordinates leaked in map tile queries or in metadata exposed in API), undermining privacy requirement of approximate locations.
Mitigation Strategy: Implement server-side fuzzing/geo-obfuscation before storing/searching; strip exact coordinates from public search results, only store precise addresses encrypted and available to authorized parties, review third-party map integrations so they only receive approximate coordinates, log and monitor access to precise location fields.

THR-009 - Application Services (Moderation Pipeline)

Category: Tampering
Likelihood: High | Impact: Medium
Risk Level: High
Description: Adversarial content engineered to bypass automated moderation (image/text obfuscation, alternate language, unicode tricks) leading to publication of spam, scams, or malicious adverts.
Mitigation Strategy: Use layered moderation: ML heuristics + deterministic rules + human review for flagged or high-risk adverts; adversarial testing of moderation models; limit feature exposure for new/low-reputation advertisers; rate-limit advert creation.

THR-010 - Application Services (Messaging)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Risk Level: High
Description: In-app moderated messaging used to exchange PII; messages stored in DB and in transit may be exposed due to weak encryption, improper RBAC, or logging of message bodies to analytics systems.
Mitigation Strategy: Encrypt messages at rest with KMS-managed keys, enforce TLS in transit, restrict access to message stores to smallest set of service accounts, redact PII in analytics pipelines, provide ephemeral message retention policies and user-controlled deletion, log only metadata not message contents.

THR-012 - Data Storage (Relational DB / Search Index)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Risk Level: High
Description: Unauthorized access to backups, snapshots, or misconfigured search index (Elasticsearch/OpenSearch) exposing full dataset including PII or sensitive adverts.
Mitigation Strategy: Enforce network-level access controls (VPC, private endpoints), enable authentication and TLS on search services, encrypt backups at rest, rotate access keys, restrict snapshot exports, and monitor/access alerts for unusual data exports.

THR-015 - External Services (Payment Gateway)

Category: Tampering
Likelihood: Medium | Impact: High
Risk Level: High
Description: Payment flow manipulation or token interception causing fraudulent premium listings, subscription status manipulation, or chargeback/fraud against the platform.
Mitigation Strategy: Use PCI-compliant gateway with tokenization (never store raw card data), validate webhooks with signatures, verify payment notification origins, reconcile subscription state server-side, implement fraud detection and anomaly monitoring, require 3DS where supported.

THR-017 - Admin & Moderation

Category: Elevation of Privilege
Likelihood: Medium | Impact: High
Risk Level: High
Description: Compromise of admin/moderator accounts via phishing or weak SSO config leading to mass approval of malicious adverts, deletion or tampering with audit logs, or user bans.
Mitigation Strategy: Use strong SSO with MFA, enforce least privilege for moderator roles (separation of duties), require justification and second approval for bulk actions, record all admin actions to immutable audit logs, and monitor for anomalous admin activity.

THR-019 - Notifications & Messaging (In-app)

Category: Denial of Service
Likelihood: High | Impact: Medium
Risk Level: High
Description: Messaging system spam or automated bots overwhelm a user’s inbox or notification system causing resource exhaustion and poor UX; attackers may use messaging to send harmful links.
Mitigation Strategy: Rate-limit message sending per account/IP, implement reputation scoring for senders, CAPTCHAs on account actions, automated content filtering, allow users to block/report senders, throttle notifications and use backpressure in queueing system.

THR-021 - External Services (Email Provider)

Category: Information Disclosure
Likelihood: Low | Impact: High
Risk Level: High
Description: Compromise or misconfiguration at the email provider leading to leakage of verification emails, digests, or password resets enabling account takeover or exposure of PII.
Mitigation Strategy: Use reputable ESP with secure contracts, enable TLS and DKIM/SPF/DMARC, minimize sensitive data in emails, send reset links that expire quickly, monitor ESP security advisories, and have incident response plan for ESP compromise.

THR-022 - Data Storage (Backups & Logs)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Risk Level: High
Description: Backups or audit logs containing historic PII retained longer than necessary, or accessible by excessive staff, leading to compliance violations (GDPR) and data breach risks.
Mitigation Strategy: Apply data retention policies and automated deletion, anonymize/pseudonymize PII where possible, restrict access to backups via IAM, encrypt backups, and periodically audit access to retention stores.

THR-023 - Frontend / Edge (CDN)

Category: Information Disclosure
Likelihood: Low | Impact: High
Risk Level: High
Description: Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pages cached publicly) exposing PII or private adverts to other users.
Mitigation Strategy: Use cache-control headers to prevent caching of personalized content, vary cache on headers appropriately, use CDN configuration to strip sensitive cookies/headers, and test CDN caching rules for unintended caching.

THR-024 - Application Services / API

Category: Tampering
Likelihood: Medium | Impact: High
Risk Level: High
Description: Injection attacks (SQL injection or NoSQL injection) via poorly validated advert fields or search parameters allowing data tampering, unauthorized data access, or remote code execution via unsafe ORM usage.
Mitigation Strategy: Use parameterized queries/ORM safe APIs, validate and constrain inputs (length/format), ORM prepared statements, adopt least-privilege DB accounts, run regular SAST/DAST and DB access monitoring, and protect admin endpoints behind stricter controls.

THR-027 - External Services (Third-party Integrations overall)

Category: Information Disclosure
Likelihood: Medium | Impact: High
Risk Level: High
Description: Over-sharing of PII to third-party analytics, logging, or ML moderation providers (sending full message bodies or exact addresses) creating compliance and privacy risk.
Mitigation Strategy: Data minimization: pseudonymize or aggregate before sending, use contracts and DPA with providers, vet security posture of providers, encrypt data in transit and at rest, and implement strict access controls on provider integrations.

THR-029 - Infrastructure / Cloud

Category: Tampering
Likelihood: Medium | Impact: High
Risk Level: High
Description: Cloud misconfigurations (open management ports, overly permissive IAM roles, publicly exposed DB or storage) allowing attackers to access or modify data and resources.
Mitigation Strategy: Implement IaC with security scanning, enforce least-privilege IAM, use VPC/private endpoints, rotate credentials, use cloud provider security posture management (CSPM), run periodic pen tests and configuration audits, and enable multi-account separation for prod/staging.

Medium Risk Threats

THR-003 - Frontend Layer

Category: Spoofing
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: UI-level phishing via malicious adverts or profiles that mimic platform branding to trick users into revealing credentials or off-platform contact details.
Mitigation Strategy: Restrict HTML/branding in adverts, enforce a platform watermark and verified-badge UI for verified advertisers, run automated moderation for suspicious branding, user education and reporting flow, and block off-platform contact until verification.

THR-011 - Notifications & Messaging (Email/Push Providers)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Sensitive information leaked via email digests or push notifications (e.g., full advert addresses, private messages) or email interception due to misconfigured email provider templates exposing PII.
Mitigation Strategy: Limit content in notifications to non-sensitive summaries, avoid including PII or exact location in emails/pushes, use secure provider configurations (TLS for SMTP, signed DKIM/SPF), allow users to opt-out of email content sharing, and review templates for accidental leakage.

THR-013 - Data Storage (Object Storage for Media)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Publicly accessible S3/Blob containers containing photos that include metadata or people could be exposed due to incorrect ACLs or predictable object URLs.
Mitigation Strategy: Use private buckets with signed, time-limited URLs for media access, strip EXIF/GPS metadata from uploaded photos, scan uploads for sensitive content, enforce upload size/content checks, and set least-privilege IAM policies for storage access.

THR-014 - External Services (Maps API)

Category: Information Disclosure
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Third-party map provider logs or telemetry reveal approximate queries or leak location metadata (e.g., passing exact coords), or attacker abuses API keys embedded in frontend to query map endpoints for data enumeration.
Mitigation Strategy: Send only obfuscated/approximate coordinates to map provider, restrict API keys via referer/IP restrictions, avoid embedding privileged keys in client, use server-side map proxy for sensitive queries, review provider’s privacy SLA.

THR-016 - Payments & Billing

Category: Repudiation
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Advertisers dispute charges or claim service not delivered; lack of reliable invoice/transaction audit trail hinders dispute resolution and may lead to financial loss.
Mitigation Strategy: Maintain tamper-evident audit logs for billing events, store payment tokenization metadata, send receipts with transaction IDs, enable immutable logs in SIEM, and retain reconciliation records per compliance retention policies.

THR-018 - Admin & Moderation

Category: Repudiation
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Insufficient or tamperable audit logs allowing admins/moderators to deny or hide actions (e.g., disabling adverts without reason), impacting incident response and compliance.
Mitigation Strategy: Use append-only, write-once audit logging (cloud-native immutability), forward logs to SIEM with restricted access, implement logging integrity checks, and enforce log retention/rotation policies for compliance.

THR-020 - Application Services (Search/Geo)

Category: Tampering
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Search index poisoning or malicious adverts crafted to manipulate search ranking (e.g., SEO spam, repeated adverts to surface malicious listings), reducing quality and user trust.
Mitigation Strategy: Rate-limit advert creation, use deduplication checks, reputation-based ranking and human review for new advertisers, monitor ranking changes, and use anomaly detection in search metrics.

THR-025 - Application Services (API)

Category: Spoofing
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: API key leakage or abuse (e.g., frontend-embedded keys used to query private endpoints or enumerate adverts), enabling attackers to harvest data or bypass quotas.
Mitigation Strategy: Never embed privileged keys in frontend, restrict keys by origin/IP and scope, rotate keys regularly, monitor key usage and set quotas, and require server-side calls for privileged operations.

THR-026 - Payments & Billing

Category: Repudiation
Likelihood: Low | Impact: Medium
Risk Level: Medium
Description: Lack of immutable proof for subscription entitlement changes leads to disputes where advertisers claim upgrades/downgrades were not applied correctly or were fraudulent.
Mitigation Strategy: Record subscription lifecycle events immutably with timestamps, require server-side confirmation flows for entitlements, keep audit trails tied to payment gateway transaction IDs, and notify users on entitlement changes.

THR-028 - Platform-wide (Account Creation & Email Domain Filtering)

Category: Spoofing
Likelihood: Medium | Impact: Medium
Risk Level: Medium
Description: Bypass of email-domain verification for free-tier advertisers using disposable university-like addresses or compromised student mailbox leading to fraudulent adverts.
Mitigation Strategy: Perform MX record checks and restrict to known university domains list, implement additional checks (SAML/IdP integration with select institutions), manual/automated scrutiny for new advertiser accounts, rate-limit new accounts, and use reputation scoring before granting free-tier privileges.

THR-030 - Platform-wide (Search & Saved Searches / Alerts)

Category: Information Disclosure
Likelihood: Low | Impact: Medium
Risk Level: Medium
Description: Saved searches and alert digest emails could be inferred by attackers to profile a user’s activity or to stalk users (e.g., frequent queries for a person’s name or location patterns).
Mitigation Strategy: Protect saved search metadata with proper ACLs, encrypt saved filters in DB if sensitive, allow users to opt-out of instant alerts, aggregate digest emails, and rate-limit alerts per user to prevent metadata leakage.

Total Threats: 30

Appendix D: Complete Requirements Traceability Matrix

This appendix provides complete end-to-end traceability from requirements through threats to controls and verification.

Full Traceability Table

Req ID	Requirement	Category	Sensitivity	Threat IDs	Security Controls	Priority	Verification	Status
REQ-001	User registration and secure login with role assig…	Authentication & Authorization	High	THR-001, THR-003, THR-004 +7	[OWASP] V2.1.1, [OWASP] V4.1.1, [NIST] IA-2 +1	Critical	Review access provisioning SOPs, sampling of access requests, and RBAC review records., Inspect identity provider configuration, review auth logs, and perform positive/negative login tests.	Pending
REQ-002	Email domain verification for free-tier advertiser…	Account Management & Verification	High	THR-006, THR-011, THR-016 +4	[OWASP] V2.2.3, [OWASP] V4.2.1, [NIST] AC-2 +1	Critical	Review service access configurations and test unauthorized access attempts., Review authorization policies and test scenarios for free vs paid users.	Pending
REQ-003	User profile management capturing display name, pr…	Data Management / Privacy	Medium	THR-001, THR-002, THR-003 +7	[ISO27001] A.18.1.4, [OWASP] V1.4.3, [NIST] AC-6 +1	Critical	Access tests for different roles and review of API authorization rules., Design review and UX testing of privacy controls; data inventory check for minimization.	Pending
REQ-004	Advert lifecycle management: create, save draft, s…	Content Management	Medium	THR-001, THR-002, THR-003 +7	[OWASP] V4.2.2, [NIST] AC-3, [OWASP] V5.1.3 +1	Critical	Policy review and data-layer query inspection for authorization predicates., Unit/integration tests for owner vs non-owner scenarios; code review of authorization checks.	Pending
REQ-005	Support property-level entry with multiple room en…	Data Model & Catalog	Low	THR-004, THR-022	None	Medium	Manual Review	Pending
REQ-006	Automatic moderation/ filtering pipeline using heu…	Moderation & Safety	High	THR-001, THR-002, THR-003 +7	None	Medium	Manual Review	Pending
REQ-007	Moderator and Administrator dashboard to review, a…	Administration & Governance	High	THR-001, THR-003, THR-004 +7	[OWASP] V4.1.3, [NIST] AC-5, [ISO27001] A.9.2.6 +1	Critical	Audit event catalog review and sampling of admin action logs., Review role definitions and evidence of dual-control workflows.	Pending
REQ-008	Geo-centric search with approximate location visua…	Search & Discovery	Low	THR-001, THR-004, THR-008 +5	[OWASP] V1.4.2, [OWASP] V9.4.1, [NIST] PL-8 +1	High	Review security architecture documents and threat models covering geo components., Review data model and retention jobs; verify only approximate location is exposed.	Pending
REQ-009	Advanced filters: price range, distance, number of…	Search & Personalisation	Low	THR-001, THR-002, THR-004 +6	None	Medium	Manual Review	Pending
REQ-010	Email alerts (instant and daily digest) and in-app…	Notifications & Engagement	Medium	THR-001, THR-002, THR-003 +7	[OWASP] V10.4.1, [OWASP] V5.4.3, [NIST] SI-4 +1	High	Review rate limit configurations and simulate high-frequency alert creation., Check monitoring rules and SIEM dashboards for alerting subsystem.	Pending
REQ-011	Favourites/bookmarks management: allow users to fa…	User Experience & Personalisation	Low	THR-001, THR-003, THR-007 +5	[OWASP] V4.3.1, [NIST] AC-16, [ISO27001] A.9.4.1 +1	Critical	Policy review and functional testing of access restrictions., Review storage encryption and access controls; test for tampering resistance.	Pending
REQ-012	Secure in-app messaging system that mediates commu…	Communication & Privacy	High	THR-001, THR-002, THR-003 +7	[OWASP] V9.2.1, [NIST] SC-13, [OWASP] V2.8.1 +1	Critical	Review cipher suites and test integrity verification on message transport., TLS configuration scan and packet inspection to confirm encryption.	Pending
REQ-013	Interactive map view using third-party mapping API…	Data Privacy & Visualisation	Medium	THR-001, THR-002, THR-006 +7	[OWASP] V1.4.1, [OWASP] V5.3.1, [NIST] SC-7 +1	High	Network configuration review and monitoring of egress to mapping services., Design review and UI tests to confirm only approximate positions are shown.	Pending
REQ-014	Reporting and abuse-flagging workflow for users to…	Safety & Trust	High	THR-001, THR-003, THR-006 +7	[NIST] AU-3, [OWASP] V7.1.1, [ISO27001] A.12.4.1 +1	High	Check logging configuration and attempt to access logs with different roles., Inspect SIEM dashboards and alert configurations for moderation events.	Pending
REQ-015	Paid-tier features: priority listing / boosted pla…	Monetisation & Analytics	Medium	THR-003, THR-010, THR-015 +3	[OWASP] V4.2.3, [OWASP] V10.4.3, [NIST] AU-2 +1	Critical	SOP review and training records., Attempt to access premium features with non-paid accounts; review authorization middleware.	Pending
REQ-016	Secure payment processing via a PCI-DSS-compliant …	Payment Processing & Compliance	High	THR-001, THR-003, THR-004 +7	[OWASP] V9.2.2, [OWASP] V9.3.2, [ISO27001] A.15.1.1 +1	Critical	TLS scan and connection tests to PSP endpoints; review client configuration., Third-party risk assessment records and periodic reassessment reports.	Pending
REQ-017	GDPR-compliant data handling: obtain explicit cons…	Legal & Privacy	High	THR-002, THR-007, THR-008 +7	[ISO27001] A.18.1.4, [OWASP] V1.4.4, [NIST] AR-8 +1	Critical	Examine consent records and test withdrawal propagation to processing systems., Review disclosure log schema and perform a test DSAR.	Pending
REQ-018	Logging, monitoring and audit trails for authentic…	Security Operations & Forensics	High	THR-007, THR-009, THR-014 +7	[OWASP] V7.1.3, [NIST] AU-8, [ISO27001] A.12.4.2 +1	Critical	Log sampling and SIEM ingestion verification for all target event types., Inspect log storage controls and integrity check outcomes.	Pending
REQ-019	Security controls including encryption in transit …	Application Security	High	THR-005, THR-007, THR-010 +7	[OWASP] V9.1.2, [NIST] SC-12, [OWASP] V2.7.5 +1	Critical	Code review of validation and gateway configs; fuzz testing of endpoints., Review data inventory and control mappings to classification levels.	Pending
REQ-020	Accessibility and responsive design to support com…	Accessibility & UX	Low	THR-001, THR-003, THR-004 +7	[OWASP] V1.3.1, [OWASP] V7.3.1, [ISO27001] A.14.2.1 +1	Low	UX review of error messages and accessibility testing., Policy review and pipeline checks for accessibility/security gates.	Pending

Total Requirements Tracked: 20

Detailed Requirement Mappings

The following section provides detailed traceability for each requirement:

REQ-001: User registration and secure login with role assignment (Advertiser, Seeker, Moderator, Administrato…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-005: Replay attacks or token theft in transit due to inadequate transport security or…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
…and 5 more threats

Security Controls:

[OWASP] V2.1.1: [OWASP] Verify that user registration and login mechanisms require robust authentication…
[OWASP] V4.1.1: [OWASP] Verify that a role-based access control (RBAC) or attribute-based access control…
[NIST] IA-2: [NIST] Identify and authenticate organizational users (and/or processes acting on behal…
[ISO27001] A.9.2.3: [ISO27001] The provisioning of user access rights shall be formalized, including assignment…

Verification: Review access provisioning SOPs, sampling of access requests, and RBAC review records., Inspect identity provider configuration, review auth logs, and perform positive/negative login tests., Review auth flow design, inspect password storage configuration, and test registration/login including account lifecycle., Policy review, code inspection of authorization middleware, and role-based access tests.

Priority: Critical | Status: Pending

REQ-002: Email domain verification for free-tier advertisers (restrict to institutional/university email doma…

Related Threats:

THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-011: Sensitive information leaked via email digests or push notifications (e.g., full…
THR-016: Advertisers dispute charges or claim service not delivered; lack of reliable inv…
THR-021: Compromise or misconfiguration at the email provider leading to leakage of verif…
THR-026: Lack of immutable proof for subscription entitlement changes leads to disputes w…
…and 2 more threats

Security Controls:

[OWASP] V2.2.3: [OWASP] Verify that the application verifies the ownership of an email address or phone …
[OWASP] V4.2.1: [OWASP] Verify that access controls enforce authorization decisions based on the authent…
[NIST] AC-2: [NIST] Manage information system accounts, including establishing, activating, modifyin…
[ISO27001] A.9.1.2: [ISO27001] Users shall only be provided with access to the network and network services tha…

Verification: Review service access configurations and test unauthorized access attempts., Review authorization policies and test scenarios for free vs paid users., Review account lifecycle automation and audit logs for state transitions., Functional tests of email verification flow and review of token expiry/one-time use implementation.

Priority: Critical | Status: Pending

REQ-003: User profile management capturing display name, profile photo, optional bio, occupation/status, and …

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-008: Exposure of exact addresses or PII via search index or API responses (e.g., deta…
…and 5 more threats

Security Controls:

[ISO27001] A.18.1.4: [ISO27001] Privacy and protection of personally identifiable information shall be ensured a…
[OWASP] V1.4.3: [OWASP] Verify that the application collects and processes only the minimum amount of pe…
[NIST] AC-6: [NIST] Employ the principle of least privilege, allowing only authorized access for use…
[OWASP] V9.1.1: [OWASP] Verify that the application protects personal data and supports data minimizatio…

Verification: Access tests for different roles and review of API authorization rules., Design review and UX testing of privacy controls; data inventory check for minimization., Review data classification and storage protections; check logs for PII leakage., Review privacy documentation, data flows, and UI settings for PII exposure.

Priority: Critical | Status: Pending

REQ-005: Support property-level entry with multiple room entities per property; each room includes cost, size…

Related Threats:

THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-022: Backups or audit logs containing historic PII retained longer than necessary, or…

Verification: Manual Review

Priority: Medium | Status: Pending

REQ-006: Automatic moderation/ filtering pipeline using heuristics and ML to detect spam, scams, malicious li…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
…and 5 more threats

Verification: Manual Review

Priority: Medium | Status: Pending

REQ-007: Moderator and Administrator dashboard to review, approve, disable, or delete adverts; manage user ac…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
…and 5 more threats

Security Controls:

[OWASP] V4.1.3: [OWASP] Verify that administrative interfaces are protected with strong authentication a…
[NIST] AC-5: [NIST] Separate duties of individuals to reduce the risk of malevolent activity without…
[ISO27001] A.9.2.6: [ISO27001] The access rights of all employees and external party users to information and i…
[NIST] AU-12: [NIST] Provide audit record generation capability for defined auditable events within t…

Verification: Audit event catalog review and sampling of admin action logs., Review role definitions and evidence of dual-control workflows., Access recertification records and deprovisioning audit trails., Check admin auth configuration, MFA enforcement, and role matrix.

Priority: Critical | Status: Pending

REQ-008: Geo-centric search with approximate location visualisation (neighbourhood or postcode area), map clu…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-008: Exposure of exact addresses or PII via search index or API responses (e.g., deta…
THR-012: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti…
THR-014: Third-party map provider logs or telemetry reveal approximate queries or leak lo…
…and 3 more threats

Security Controls:

[OWASP] V1.4.2: [OWASP] Verify that the application limits collection and retention of location and othe…
[OWASP] V9.4.1: [OWASP] Verify that sensitive data such as geolocation is not exposed in logs or through…
[NIST] PL-8: [NIST] Develop an information security architecture for the system that describes the r…
[ISO27001] A.18.1.5: [ISO27001] Cryptographic controls shall be used in compliance with all relevant agreements,…

Verification: Review security architecture documents and threat models covering geo components., Review data model and retention jobs; verify only approximate location is exposed., API response and log sampling to confirm no precise coordinates are present., Crypto configuration review and TLS scanning of map endpoints.

Priority: High | Status: Pending

REQ-009: Advanced filters: price range, distance, number of housemates, amenities, stay duration, household p…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-009: Adversarial content engineered to bypass automated moderation (image/text obfusc…
…and 4 more threats

Verification: Manual Review

Priority: Medium | Status: Pending

REQ-010: Email alerts (instant and daily digest) and in-app notifications for new adverts matching saved sear…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
…and 5 more threats

Security Controls:

[OWASP] V10.4.1: [OWASP] Verify that the application enforces business logic with appropriate limits and …
[OWASP] V5.4.3: [OWASP] Verify that untrusted data is properly sanitized and output encoded to prevent i…
[NIST] SI-4: [NIST] Monitor the information system to detect attacks and indicators of potential att…
[ISO27001] A.12.1.3: [ISO27001] The use of resources shall be monitored, tuned and projections made of future ca…

Verification: Review rate limit configurations and simulate high-frequency alert creation., Check monitoring rules and SIEM dashboards for alerting subsystem., Review templates and perform injection tests in alert content., Review capacity dashboards and auto-scaling policies.

Priority: High | Status: Pending

REQ-011: Favourites/bookmarks management: allow users to favourite adverts/rooms, organise lists (tags/folder…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
THR-018: Insufficient or tamperable audit logs allowing admins/moderators to deny or hide…
THR-023: Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pag…
…and 3 more threats

Security Controls:

[OWASP] V4.3.1: [OWASP] Verify that users can only access their own records, such as personal lists, fav…
[NIST] AC-16: [NIST] Associate security attributes with information by information systems and enforc…
[ISO27001] A.9.4.1: [ISO27001] Access to information and application system functions shall be restricted in ac…
[OWASP] V9.3.1: [OWASP] Verify that sensitive stored data is protected from unauthorized access and tamp…

Verification: Policy review and functional testing of access restrictions., Review storage encryption and access controls; test for tampering resistance., Conduct IDOR testing on list endpoints and inspect ORM scoping rules., Review database schema and policy enforcement logic for attribute checks.

Priority: Critical | Status: Pending

REQ-012: Secure in-app messaging system that mediates communications between seekers and advertisers and stor…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-005: Replay attacks or token theft in transit due to inadequate transport security or…
…and 5 more threats

Security Controls:

[OWASP] V9.2.1: [OWASP] Verify that all sensitive communications are encrypted in transit using secure p…
[NIST] SC-13: [NIST] Employ cryptographic mechanisms to prevent unauthorized disclosure of informatio…
[OWASP] V2.8.1: [OWASP] Verify that re-authentication or step-up authentication is required before perfo…
[ISO27001] A.13.2.3: [ISO27001] Information involved in electronic messaging shall be appropriately protected.

Verification: Review cipher suites and test integrity verification on message transport., TLS configuration scan and packet inspection to confirm encryption., Functional test of step-up flow and token expiry behavior., Policy review and storage configuration checks; access audit for admin views.

Priority: Critical | Status: Pending

REQ-013: Interactive map view using third-party mapping APIs with clustering and obfuscation of exact coordin…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-002: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-008: Exposure of exact addresses or PII via search index or API responses (e.g., deta…
THR-009: Adversarial content engineered to bypass automated moderation (image/text obfusc…
…and 5 more threats

Security Controls:

[OWASP] V1.4.1: [OWASP] Verify that privacy requirements such as data minimization and anonymization are…
[OWASP] V5.3.1: [OWASP] Verify that data rendered in the UI, including maps and visualizations, is prope…
[NIST] SC-7: [NIST] Monitor and control communications at the external boundary and key internal bou…
[ISO27001] A.14.2.1: [ISO27001] Rules for the development of software and systems shall be established and appli…

Verification: Network configuration review and monitoring of egress to mapping services., Design review and UI tests to confirm only approximate positions are shown., Check SDLC policy adherence and code review records for map modules., Dynamic application security testing for XSS in map components.

Priority: High | Status: Pending

REQ-014: Reporting and abuse-flagging workflow for users to report suspicious adverts or users, with automate…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
THR-009: Adversarial content engineered to bypass automated moderation (image/text obfusc…
…and 5 more threats

Security Controls:

[NIST] AU-3: [NIST] Ensure that audit records contain information that establishes what events occur…
[OWASP] V7.1.1: [OWASP] Verify that all security-relevant events are logged, including authentication, a…
[ISO27001] A.12.4.1: [ISO27001] Event logs recording user activities, exceptions, faults and information securit…
[NIST] AU-6: [NIST] Review and analyze information system audit records for indications of inappropr…

Verification: Check logging configuration and attempt to access logs with different roles., Inspect SIEM dashboards and alert configurations for moderation events., Review log review procedures and evidence of periodic reviews., Review audit log fields and sample records for completeness.

Priority: High | Status: Pending

REQ-015: Paid-tier features: priority listing / boosted placement, branding fields, extended descriptions, an…

Related Threats:

THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-010: In-app moderated messaging used to exchange PII; messages stored in DB and in tr…
THR-015: Payment flow manipulation or token interception causing fraudulent premium listi…
THR-020: Search index poisoning or malicious adverts crafted to manipulate search ranking…
THR-026: Lack of immutable proof for subscription entitlement changes leads to disputes w…
…and 1 more threats

Security Controls:

[OWASP] V4.2.3: [OWASP] Verify that the application enforces authorization checks for each function, esp…
[OWASP] V10.4.3: [OWASP] Verify that business logic enforces integrity of transactions and prevents abuse…
[NIST] AU-2: [NIST] Define auditable events and ensure that the information system generates audit r…
[ISO27001] A.12.1.1: [ISO27001] Operating procedures shall be documented and made available to all users who nee…

Verification: SOP review and training records., Attempt to access premium features with non-paid accounts; review authorization middleware., Audit event catalog review and sampling of payment-related logs., Business logic tests simulating tampering with client-side flags and stale receipts.

Priority: Critical | Status: Pending

REQ-016: Secure payment processing via a PCI-DSS-compliant gateway for subscriptions and one-off payments; do…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-005: Replay attacks or token theft in transit due to inadequate transport security or…
THR-006: Credential stuffing, weak password reuse, or brute-force attacks leading to acco…
…and 5 more threats

Security Controls:

[OWASP] V9.2.2: [OWASP] Verify that connections to external payment service providers use strong TLS and…
[OWASP] V9.3.2: [OWASP] Verify that payment-related data stored is minimized and protected using strong …
[ISO27001] A.15.1.1: [ISO27001] Information security requirements for mitigating the risks associated with suppl…
[NIST] SA-9: [NIST] Require that providers of external information system services comply with organ…

Verification: TLS scan and connection tests to PSP endpoints; review client configuration., Third-party risk assessment records and periodic reassessment reports., Supplier agreement review and third-party assurance evidence., Data inventory and storage encryption configuration review; access audit.

Priority: Critical | Status: Pending

REQ-018: Logging, monitoring and audit trails for authentication events, moderation actions, payment transact…

Related Threats:

THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
THR-009: Adversarial content engineered to bypass automated moderation (image/text obfusc…
THR-014: Third-party map provider logs or telemetry reveal approximate queries or leak lo…
THR-015: Payment flow manipulation or token interception causing fraudulent premium listi…
THR-016: Advertisers dispute charges or claim service not delivered; lack of reliable inv…
…and 5 more threats

Security Controls:

[OWASP] V7.1.3: [OWASP] Verify that logs are generated for administrative actions, access control events…
[NIST] AU-8: [NIST] Use internal system clocks to generate time stamps for audit records with suffic…
[ISO27001] A.12.4.2: [ISO27001] Logging facilities and log information shall be protected against tampering and …
[NIST] AU-9: [NIST] Protect audit information and audit tools from unauthorized access, modification…

Verification: Log sampling and SIEM ingestion verification for all target event types., Inspect log storage controls and integrity check outcomes., Check NTP configuration and compare timestamps across services., Access review for log tools and attempted unauthorized modification test.

Priority: Critical | Status: Pending

REQ-019: Security controls including encryption in transit (TLS), encryption at rest for PII and payment toke…

Related Threats:

THR-005: Replay attacks or token theft in transit due to inadequate transport security or…
THR-007: Broken access control allowing privilege escalation (e.g., seeker modifies reque…
THR-010: In-app moderated messaging used to exchange PII; messages stored in DB and in tr…
THR-012: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti…
THR-013: Publicly accessible S3/Blob containers containing photos that include metadata o…
…and 5 more threats

Security Controls:

[OWASP] V9.1.2: [OWASP] Verify that all sensitive data is identified and classified, and appropriate pro…
[NIST] SC-12: [NIST] Establish and manage cryptographic keys for required cryptography employed withi…
[OWASP] V2.7.5: [OWASP] Verify that session management and authentication support multi-factor authentic…
[NIST] SI-10: [NIST] Check the validity of information inputs.

Verification: Code review of validation and gateway configs; fuzz testing of endpoints., Review data inventory and control mappings to classification levels., Test MFA enrollment and enforcement; review auth configuration., Key management policy review and evidence of key rotation/audit logs.

Priority: Critical | Status: Pending

REQ-020: Accessibility and responsive design to support common browsers and mobile devices, and target WCAG 2…

Related Threats:

THR-001: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,…
THR-003: UI-level phishing via malicious adverts or profiles that mimic platform branding…
THR-004: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv…
THR-011: Sensitive information leaked via email digests or push notifications (e.g., full…
THR-012: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti…
…and 5 more threats

Security Controls:

[OWASP] V1.3.1: [OWASP] Verify that security is addressed in user experience and design, including error…
[OWASP] V7.3.1: [OWASP] Verify that error messages are handled in a user-friendly manner without reveali…
[ISO27001] A.14.2.1: [ISO27001] Rules for the development of software and systems shall be established and appli…
[NIST] RA-5: [NIST] Scan for vulnerabilities in the information system and hosted applications and a…

Verification: UX review of error messages and accessibility testing., Policy review and pipeline checks for accessibility/security gates., Scan reports and remediation tracking., UI testing for error content and accessibility audits.

Priority: Low | Status: Pending

Appendix E: References

End of Report - Generated by Security Requirements Analysis System v2.0 Generated: 2025-11-25 17:05:39

--- title: "Security Requirements Analysis Report" subtitle: "Comprehensive Security Analysis with Interactive Dashboard" author: "Security Requirements System v2.0" date: "2025-11-25 17:05:39" format: html: page-layout: full toc: true toc-depth: 3 toc-location: left embed-resources: true code-fold: true code-tools: true fig-width: 8 fig-height: 5 fig-dpi: 300 number-sections: false smooth-scroll: true mermaid-format: svg execute: echo: false warning: false message: false freeze: auto jupyter: python3 --- *Generated: 2025-11-25 17:05:39* *Report Version: 2.0 - Comprehensive Security Analysis* --- ## 1. Executive Summary This section provides a high-level overview of the security requirements analysis, presenting key findings, validation results, and an interactive dashboard for stakeholders and decision-makers. The executive summary enables rapid comprehension of the security posture, critical risks, control coverage, and compliance status without requiring detailed technical knowledge. ### 1.1. Purpose and Scope **Purpose** This document presents a comprehensive security requirements analysis for the proposed application, systematically mapping high-level business requirements to specific, actionable security controls aligned with multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. The analysis provides a complete security requirements specification that guides secure system design, implementation, and verification. **Scope** This analysis encompasses all functional requirements provided, delivering comprehensive coverage across multiple security domains: - **Requirements Analysis**: Systematic decomposition and security-relevant extraction from business requirements - **Stakeholder Analysis**: Identification of stakeholders, trust boundaries, and security responsibilities - **Threat Modeling**: Systematic identification and assessment of security threats using STRIDE methodology - **Security Control Mapping**: Mapping requirements to multi-standard security controls (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed implementation guidance - **Compliance Requirements**: Identification of regulatory and legal compliance obligations - **Architectural Security**: Security architecture recommendations and design patterns - **Implementation Planning**: Prioritized, phased implementation roadmap - **Verification Strategies**: Testing and validation approaches for security controls The analysis provides both strategic guidance for security planning and tactical details for implementation teams. ### 1.2. Key Findings This section summarizes the most critical results from the security requirements analysis, providing executives and stakeholders with immediate insight into the security posture and validation status. **Analysis Metrics** - **Validation Score**: 0.88/1.0 - **Validation Status**: ✅ Passed - **Analysis Iterations**: 1 - **Requirements Analyzed**: 20 **Application Summary** A geo-centric web and mobile-optimised platform for advertising and discovering vacancies in student household sharehouses and finding compatible housemates. The system emphasises approximate-location search and map visualisation, secure mediated communication, role-based user management (advertisers, seekers, moderators, admins), automated and human moderation for safety and quality, paid-tier premium advertising with payment integration, and GDPR-compliant handling of personal data and communications while protecting exact addresses and contact details to preserve privacy and safety. The validation score reflects the quality and completeness of the security requirements across five dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. A score of 0.8 or higher indicates that the requirements are ready for implementation, while scores below this threshold may require refinement before proceeding. ### 1.3. Security Overview Dashboard This interactive dashboard provides executive-level visualization of key security metrics and trends, enabling rapid assessment of the security posture through intuitive charts and data visualizations. The dashboard presents critical information across multiple dimensions: risk distribution, security control coverage, compliance status, implementation progress, and data quality metrics. For optimal viewing experience, render this document with Quarto to enable interactive chart functionality, allowing stakeholders to explore data dynamically and drill down into specific areas of interest. ::: {.panel-tabset} #### Risk ```{python} #| label: load-metrics #| echo: false #| warning: false import json import pandas as pd from pathlib import Path # Load dashboard data artifacts artifacts_path = Path("artifacts_20251125_170539") threats = pd.read_json(artifacts_path / "threats.json") asvs = pd.read_json(artifacts_path / "asvs_mapping.json") priorities = pd.read_json(artifacts_path / "priorities.json") compliance = pd.read_json(artifacts_path / "compliance.json") delivery = pd.read_json(artifacts_path / "delivery.json") coverage = pd.read_json(artifacts_path / "coverage.json") validation = json.loads((artifacts_path / "validation.json").read_text()) ``` ```{python} #| label: fig-risk-heatmap #| fig-cap: "Risk heat map showing threat distribution by likelihood and impact (1-5 scale)." #| echo: false #| warning: false try: import plotly.express as px import plotly.graph_objects as go # Create risk heatmap heat = threats.groupby(["likelihood", "impact"]).size().reset_index(name="count") # Create a complete 5x5 grid import numpy as np l_range = range(1, 6) i_range = range(1, 6) grid_data = [] for l in l_range: for i in i_range: count = heat[(heat["likelihood"] == l) & (heat["impact"] == i)]["count"].sum() grid_data.append({"likelihood": l, "impact": i, "count": int(count)}) heat_df = pd.DataFrame(grid_data) pivot = heat_df.pivot(index="impact", columns="likelihood", values="count").fillna(0) fig_risk = go.Figure(data=go.Heatmap( z=pivot.values, x=[f"L{x}" for x in pivot.columns], y=[f"I{y}" for y in pivot.index], text=pivot.values, texttemplate="%{text:.0f}", textfont={"size": 12}, colorscale="YlOrRd", hoverongaps=False )) fig_risk.update_layout( title="Threat Risk Matrix (Likelihood × Impact)", xaxis_title="Likelihood →", yaxis_title="Impact →", width=800, height=400 ) fig_risk.show() except Exception as e: print(f"⚠️ Could not generate risk heatmap: {e}") print("\nRisk Distribution (Static):") print(threats.groupby("risk_level").size()) ``` **Top 5 Highest Risks:** ```{python} #| echo: false #| output: asis #| warning: false top_risks = threats.nlargest(5, ["likelihood", "impact"]) for idx, risk_row in top_risks.iterrows(): risk_id = risk_row['id'] risk_level = risk_row['risk_level'] component = risk_row.get('component', 'Unknown Component') category = risk_row.get('category', 'N/A') likelihood = risk_row.get('likelihood', 'N/A') impact = risk_row.get('impact', 'N/A') description = risk_row['description'] print(f"**{risk_id}** ({risk_level}) - {component}") print(f"- **Category:** {category}") print(f"- **Likelihood:** {likelihood} | **Impact:** {impact}") print(f"- **Description:** {description}") print("") ``` #### Controls ```{python} #| label: fig-standard-distribution #| fig-cap: "Security control distribution by standard (OWASP, NIST, ISO 27001)." #| echo: false #| warning: false try: import plotly.express as px # Group by standard if "standard" in asvs.columns: dist = asvs.groupby("standard").size().reset_index(name="controls") dist = dist.sort_values("controls", ascending=False) # Add percentage for better context total = dist["controls"].sum() dist["percentage"] = (dist["controls"] / total * 100).round(1) # Map standard codes to display names standard_names = { "OWASP": "OWASP ASVS", "NIST": "NIST SP 800-53", "ISO27001": "ISO 27001:2022" } dist["standard_name"] = dist["standard"].map(standard_names).fillna(dist["standard"]) fig_std = px.bar( dist, x="standard_name", y="controls", text=[f"{c}<br>({p}%)" for c, p in zip(dist["controls"], dist["percentage"])], title="Security Controls by Standard", labels={"standard_name": "Security Standard", "controls": "Control Count"}, color="controls", color_continuous_scale="Blues" ) fig_std.update_traces(textposition='outside') fig_std.update_layout(width=800, height=400, showlegend=False) fig_std.show() else: print("Standard distribution data not available.") except Exception as e: print(f"⚠️ Could not generate standard distribution chart: {e}") ``` ```{python} #| label: fig-asvs-distribution #| fig-cap: "OWASP ASVS control distribution by verification category (V1-V14)." #| echo: false #| warning: false try: import plotly.express as px # Filter to OWASP controls only asvs_owasp = asvs[asvs["standard"] == "OWASP"] if "standard" in asvs.columns else asvs # Group by ASVS category dist = asvs_owasp.groupby("v_category").size().reset_index(name="controls") dist = dist.sort_values("v_category") # Add percentage for better context total = dist["controls"].sum() dist["percentage"] = (dist["controls"] / total * 100).round(1) if total > 0 else 0 fig_asvs = px.bar( dist, x="v_category", y="controls", text=[f"{c}<br>({p}%)" for c, p in zip(dist["controls"], dist["percentage"])], title="OWASP ASVS Controls by Verification Category", labels={"v_category": "ASVS Category", "controls": "Control Count"}, color="controls", color_continuous_scale="Blues" ) fig_asvs.update_traces(textposition='outside') fig_asvs.update_layout(width=800, height=400, showlegend=False) fig_asvs.show() except Exception as e: print(f"⚠️ Could not generate ASVS chart: {e}") ``` ```{python} #| label: fig-priority-breakdown #| fig-cap: "Security control priority distribution (Critical/High/Medium/Low)." #| echo: false #| warning: false try: import plotly.express as px # Priority breakdown with color mapping color_map = { "Critical": "#c62828", "High": "#f57c00", "Medium": "#fbc02d", "Low": "#388e3c" } # Sort by priority level priority_order = ["Critical", "High", "Medium", "Low"] priorities_sorted = priorities.set_index("level").reindex(priority_order).reset_index() fig_prio = px.bar( priorities_sorted, x="level", y="count", text="count", title="Control Priority Breakdown", labels={"level": "Priority Level", "count": "Number of Controls"}, color="level", color_discrete_map=color_map ) fig_prio.update_traces(textposition='outside') fig_prio.update_layout(width=800, height=400, showlegend=False) fig_prio.show() except Exception as e: print(f"⚠️ Could not generate priority chart: {e}") ``` **Coverage Metrics:** ```{python} #| echo: false #| output: asis #| warning: false total_controls = len(asvs) total_reqs = len(coverage) req_coverage = (coverage["has_controls"].mean() * 100) if not coverage.empty else 0 verif_coverage = (coverage["tests"].gt(0).mean() * 100) if not coverage.empty else 0 # Calculate additional metrics avg_controls_per_req = (total_controls / total_reqs) if total_reqs > 0 else 0 critical_controls = len(asvs[asvs["priority"] == "Critical"]) if "priority" in asvs.columns else 0 # Calculate standard distribution if available if "standard" in asvs.columns: std_counts = asvs["standard"].value_counts() owasp_count = std_counts.get("OWASP", 0) nist_count = std_counts.get("NIST", 0) iso_count = std_counts.get("ISO27001", 0) print(f"- **Total Security Controls Mapped:** {total_controls}") print(f" - OWASP ASVS: {owasp_count} controls") print(f" - NIST SP 800-53: {nist_count} controls") print(f" - ISO 27001: {iso_count} controls") else: print(f"- **Total Security Controls Mapped:** {total_controls} (OWASP ASVS, NIST SP 800-53, ISO 27001)") print(f"- **Requirements with Security Control Mapping:** {req_coverage:.1f}% ({coverage['has_controls'].sum()}/{total_reqs})") print(f"- **Average Controls per Requirement:** {avg_controls_per_req:.1f}") print(f"- **Critical Controls:** {critical_controls} ({critical_controls/total_controls*100:.1f}% of total)" if total_controls > 0 else "- **Critical Controls:** {critical_controls}") print(f"- **Requirements with Verification:** {verif_coverage:.1f}% ({coverage['tests'].gt(0).sum()}/{total_reqs})") print(f"- **Recommended ASVS Level:** L2 (Standard)") ``` #### Compliance ```{python} #| label: fig-compliance-rag #| fig-cap: "Compliance status across all applicable frameworks (Red-Amber-Green rating). Shows regulatory compliance (GDPR, HIPAA, PCI-DSS, etc.) and security standards (OWASP ASVS, NIST SP 800-53, ISO 27001)." #| echo: false #| warning: false try: import plotly.express as px # Show all compliance frameworks (regulatory and security standards) comp_filtered = compliance # Compliance RAG status status_map = { "Compliant": "#2e7d32", "In Progress": "#f9a825", "Gap": "#c62828" } # Sort frameworks alphabetically comp_sorted = comp_filtered.sort_values("framework") fig_comp = px.bar( comp_sorted, x="framework", y=[1] * len(comp_sorted), # Equal height bars color="status", color_discrete_map=status_map, title="Compliance Status Across All Frameworks", labels={"framework": "Framework", "y": ""}, text="status", height=400 ) fig_comp.update_layout(width=800, height=400, showlegend=True, yaxis_visible=False, yaxis_showticklabels=False) fig_comp.update_traces(textposition='inside') fig_comp.show() except Exception as e: print(f"⚠️ Could not generate compliance chart: {e}") print("\nCompliance Status (Static):") for _, row in compliance.iterrows(): print(f"- **{row['framework']}**: {row['status']}") ``` **Compliance Summary:** ```{python} #| echo: false #| output: asis #| warning: false for _, row in compliance.iterrows(): status_icon = "✅" if row["status"] == "Compliant" else "⚠️" if row["status"] == "In Progress" else "❌" print(f"- {status_icon} **{row['framework']}**: {row['status']} (Next Audit: {row['next_audit']})") ``` #### Delivery ```{python} #| label: fig-delivery-burndown #| fig-cap: "Projected implementation timeline by phase and week (based on priority-based planning)." #| echo: false #| warning: false try: import plotly.express as px import plotly.graph_objects as go # Create burndown chart with planned vs projected completion fig_burn = go.Figure() for phase in delivery["phase"].unique(): phase_data = delivery[delivery["phase"] == phase] # Planned line fig_burn.add_trace(go.Scatter( x=phase_data["week"], y=phase_data["planned"], mode='lines', name=f"{phase} (Planned)", line=dict(dash='dash', color='gray'), showlegend=True )) # Projected completion line fig_burn.add_trace(go.Scatter( x=phase_data["week"], y=phase_data["completed"], mode='lines+markers', name=f"{phase} (Projected)", showlegend=True )) fig_burn.update_layout( title="Security Controls Implementation Timeline (Projected)", xaxis_title="Week", yaxis_title="Number of Controls", width=800, height=400, hovermode='x unified' ) fig_burn.show() except Exception as e: print(f"⚠️ Could not generate delivery chart: {e}") ``` **Implementation Timeline (Projected):** ```{python} #| echo: false #| output: asis #| warning: false phase1 = delivery[delivery["phase"].str.contains("Phase 1")] phase2 = delivery[delivery["phase"].str.contains("Phase 2")] if not phase1.empty: p1_progress = (phase1["completed"].iloc[-1] / phase1["planned"].iloc[-1] * 100) if phase1["planned"].iloc[-1] > 0 else 0 print(f"- **Phase 1 (Critical/High):** {p1_progress:.0f}% projected completion (Weeks 1-8)") if not phase2.empty: p2_progress = (phase2["completed"].iloc[-1] / phase2["planned"].iloc[-1] * 100) if phase2["planned"].iloc[-1] > 0 else 0 print(f"- **Phase 2 (Medium):** {p2_progress:.0f}% projected completion (Weeks 9-16)") print(f"- **Phase 3 (Low/Ongoing):** Continuous improvement and monitoring") print(f"") print(f"*Note: Timeline is based on priority-based planning and assumes steady implementation progress.*") ``` #### Data Quality **Validation Metrics:** ```{python} #| echo: false #| output: asis #| warning: false val_score = validation.get("score", 0) val_passed = validation.get("passed", False) dims = validation.get("dims", {}) status_icon = "✅" if val_passed else "⚠️" if val_score >= 0.7 else "❌" print(f"") print(f"**Overall Validation Score:** {status_icon} {val_score:.2f}/1.0") print(f"") if dims: print("**Dimension Scores:**") print(f"") for dim, score in dims.items(): dim_icon = "✅" if score >= 0.8 else "⚠️" if score >= 0.7 else "❌" print(f"- {dim_icon} **{dim.capitalize()}:** {score:.2f}") else: print("*Dimension scores not available.*") ``` ```{python} #| label: fig-data-quality #| fig-cap: "Data quality and coverage metrics." #| echo: false #| warning: false try: import plotly.graph_objects as go # Calculate quality metrics threats_linked_pct = (coverage["has_threat"].mean() * 100) if not coverage.empty else 0 # Calculate average controls per requirement avg_controls_per_req = (total_controls / total_reqs) if total_reqs > 0 else 0 # For the chart, we'll show percentage-based metrics and handle avg controls separately metrics = { "Requirements Mapped": req_coverage, "Threats Linked": threats_linked_pct, "Verification Coverage": verif_coverage, "Avg Controls/Req": avg_controls_per_req * 20, # Scale for visual comparison (multiply by 20 to fit chart scale) "Validation Score": val_score * 100 } # Create custom text labels (show actual values for avg controls, percentages for others) text_labels = [] for key, val in metrics.items(): if key == "Avg Controls/Req": text_labels.append(f"{avg_controls_per_req:.1f}") else: text_labels.append(f"{val:.1f}%") fig_quality = go.Figure(go.Bar( x=list(metrics.values()), y=list(metrics.keys()), orientation='h', text=text_labels, textposition='outside', marker=dict( color=list(metrics.values()), colorscale='RdYlGn', cmin=0, cmax=100 ) )) fig_quality.update_layout( title="Data Quality & Coverage Metrics", xaxis_title="Score / Percentage (%)", xaxis=dict(range=[0, 110]), width=800, height=400, showlegend=False ) fig_quality.show() except Exception as e: print(f"⚠️ Could not generate quality chart: {e}") ``` ```{python} #| echo: false #| output: asis #| warning: false # Parser and data quality stats total_entries = len(coverage) with_threats = coverage["has_threat"].sum() with_controls = coverage["has_controls"].sum() with_tests = coverage["tests"].gt(0).sum() print(f"") print(f"**Traceability Matrix:**") print(f"") print(f"- Total Requirements: {total_entries}") print(f"- Linked to Threats: {with_threats} ({with_threats/max(total_entries,1)*100:.1f}%)") print(f"- Mapped to Security Controls: {with_controls} ({with_controls/max(total_entries,1)*100:.1f}%)") print(f"- With Verification: {with_tests} ({with_tests/max(total_entries,1)*100:.1f}%)") print(f"") print(f"**Data Quality:** {"✅ Excellent" if val_score >= 0.8 else "⚠️ Good" if val_score >= 0.7 else "❌ Needs Improvement"}") ``` ::: --- ## 2. Requirements Understanding This section presents a comprehensive analysis of the functional requirements, extracting security-relevant information and establishing the foundation for the security requirements specification. Understanding the functional requirements is essential for identifying security implications, data sensitivity, trust boundaries, and security-critical components. This analysis transforms business requirements into security-aware specifications that inform threat modeling, control selection, and compliance assessment. ### 2.1. High-Level Requirements Analysis The following high-level functional requirements have been identified and analyzed for security implications: 1. User registration and login with role assignment and secure authentication 2. Email domain verification and tier-based access controls (free vs paid advertisers) 3. User profile management with verifiable contact display options 4. Advert creation, edit, delete lifecycle with support for multi-room properties 5. Automated and manual moderation workflow for adverts and content 6. Geo-centric search and filtered discovery with map visualisation (approximate locations) 7. Advanced filtering, saveable searches, and alerting (instant and daily digest) 8. Favourites/bookmarking and personalised saved-advert lists with organisation tools 9. Secure in-app messaging between users with optional verified contact reveal 10. Interactive map with clustering and approximate location display 11. Notifications system for adverts, messages and moderation status 12. Administrator and moderator dashboard for content, user and role management 13. Reporting and abuse-flagging system with dispute handling 14. Automated expiry handling and lifecycle enforcement for adverts 15. Paid-tier features: priority listing, branding, analytics, subscription and one-off payments 16. Secure payment gateway integration and payment record management 17. Logging, audit trails, and analytics for moderation, payments and admin actions 18. Privacy and data protection controls (GDPR compliance, consent management, data subject requests) 19. Security controls: encryption in transit and at rest, RBAC, MFA option, rate limiting and anti-abuse protections 20. Accessibility and mobile responsiveness (WCAG conformance target) ### 2.2. Detailed Requirements Breakdown | Req ID | Requirement | Business Category | Security Sensitivity | Data Classification | |--------|-------------|-------------------|---------------------|---------------------| | REQ-001 | User registration and secure login with role assig... | Authentication & Authorization | High | Confidential | | REQ-002 | Email domain verification for free-tier advertiser... | Account Management & Verification | High | Confidential | | REQ-003 | User profile management capturing display name, pr... | Data Management / Privacy | Medium | Confidential | | REQ-004 | Advert lifecycle management: create, save draft, s... | Content Management | Medium | Public | | REQ-005 | Support property-level entry with multiple room en... | Data Model & Catalog | Low | Public | | REQ-006 | Automatic moderation/ filtering pipeline using heu... | Moderation & Safety | High | Internal | | REQ-007 | Moderator and Administrator dashboard to review, a... | Administration & Governance | High | Internal | | REQ-008 | Geo-centric search with approximate location visua... | Search & Discovery | Low | Public | | REQ-009 | Advanced filters: price range, distance, number of... | Search & Personalisation | Low | Public | | REQ-010 | Email alerts (instant and daily digest) and in-app... | Notifications & Engagement | Medium | Internal | | REQ-011 | Favourites/bookmarks management: allow users to fa... | User Experience & Personalisation | Low | Internal | | REQ-012 | Secure in-app messaging system that mediates commu... | Communication & Privacy | High | Confidential | | REQ-013 | Interactive map view using third-party mapping API... | Data Privacy & Visualisation | Medium | Public | | REQ-014 | Reporting and abuse-flagging workflow for users to... | Safety & Trust | High | Internal | | REQ-015 | Paid-tier features: priority listing / boosted pla... | Monetisation & Analytics | Medium | Internal | | REQ-016 | Secure payment processing via a PCI-DSS-compliant ... | Payment Processing & Compliance | High | Restricted | | REQ-017 | GDPR-compliant data handling: obtain explicit cons... | Legal & Privacy | High | Confidential | | REQ-018 | Logging, monitoring and audit trails for authentic... | Security Operations & Forensics | High | Internal | | REQ-019 | Security controls including encryption in transit ... | Application Security | High | Confidential | | REQ-020 | Accessibility and responsive design to support com... | Accessibility & UX | Low | Public | ### 2.3. Security Context and Regulatory Obligations Applicable regulations and obligations include: GDPR (EU/EEA/UK) for personal data processing, data subject rights and consent management; ePrivacy rules for electronic marketing and email notifications; PCI-DSS obligations for any payment card processing or token storage; national consumer protection and housing anti-discrimination laws applicable to adverts (platform should enforce non-discriminatory advertising policies); local data residency or export control laws if hosting data in or for specific jurisdictions; WCAG accessibility standards (target WCAG 2.1 AA); obligations to preserve and produce records for lawful requests (law enforcement). Platform must also consider obligations under consumer protection and payment service regulations where relevant (e.g., VAT collection, invoicing for B2B advertisers). ### 2.4. Assumptions - System will be cloud-hosted (public cloud) with support for region-based data residency where required. - Third-party services will be used for mapping (e.g., Google Maps, Mapbox), email delivery, and payments (PCI-compliant gateway). - Moderation combines automated tools and human moderators; moderators are trusted and trained staff with appropriate background checks. - Advertisers and users are primarily adults (18+); platform will implement age gating or explicit checks if minors are supported. - Universities will provide or have publicly available email domain lists for domain-restricted signups, or a maintainable allowlist will be created. - Users have internet access and modern browsers or mobile devices; push notifications rely on standard web/mobile push services. - Paid-tier customers will use the provided payment options and accept the platform's terms; recurring subscription billing will be supported. - Platform will not publish exact addresses publicly; precise coordinates may be stored internally for authorised use (e.g., emergency/legal requests) with strict access controls. ### 2.5. Constraints - Exact addresses must not be displayed publicly — only approximate locations (neighbourhood/postcode/geohash) permitted for privacy and safety. - Integration with third-party mapping and payment providers introduces dependencies on their APIs, SLAs, and pricing. - Moderation pipeline (automated + human) may introduce publication latency; SLAs for advert approval must balance speed and safety. - Payment processing requires PCI-DSS compliance or use of a tokenizing gateway to avoid storing sensitive card data on-platform. - Data residency and local privacy regulations may require regional hosting or data segregation for EU/UK users. - Scalability and rate limiting requirements must be designed to handle dense clusters (e.g., high advert volumes in university towns) without degrading search performance. - Retention policies for logs, messages and adverts must be defined to meet legal and operational needs but may conflict with user 'right to be forgotten' timelines — implementation must reconcile both. - Accessibility (WCAG) and cross-browser mobile support constrain front-end frameworks and testing matrices. - Anti-abuse measures (rate limits, CAPTCHAs, content filters) must avoid impeding legitimate users while blocking bots and fraud attempts. --- ## 3. Stakeholder Analysis This section identifies and analyzes all stakeholders involved in or affected by the system, including users, administrators, external partners, and regulatory bodies. Stakeholder analysis establishes trust boundaries, defines security responsibilities, and identifies potential security concerns from different stakeholder perspectives. Understanding stakeholder relationships and trust boundaries is critical for designing appropriate access controls, authentication mechanisms, and data protection measures. ### 3.1. Identified Stakeholders and User Personas | Role | Privilege Level | Trust Level | Key Security Concerns | |-----------------------------|-----------------|------------------|----------------------------------------------------------------------------------| | Advertiser | User | Partially Trusted | Unverified listings leading to fraudulent adverts, unauthorized access to personal data. | | Seeker | User | Partially Trusted | Phishing attacks via in-app messaging, data exposure during search. | | Moderator | Admin | Trusted | Mismanagement of adverts leading to inappropriate content remaining published, insider threats. | | Administrator | Admin | Trusted | Full access to user data and adverts, potential for data breaches through privilege misuse. | | Agency | Paid Tier User | Partially Trusted | Misrepresentation of properties, unauthorized access to sensitive payment information. | | Temporary Accommodation | Paid Tier User | Partially Trusted | Data exposure risks when handling multiple listings, potential for account misuse. | | System APIs | Service Account | Trusted | Insecure API access exposing user data, improper authentication leading to unauthorized actions. | | Email Notification Service | Service Account | Trusted | Data leaks through improper handling of user information, lack of consent management. | | Payment Gateway | Service Account | Trusted | PCI compliance risks, potential for data breaches during transaction processing. | | Mapping API | Service Account | Partially Trusted | Data exposure through unsecured API calls, insufficient access controls on location data. | ### 3.2. Trust Model Trust boundaries are established at the user interface, backend server, and database levels. Security mechanisms enforcing boundaries include user authentication (email/password and domain verification), role-based access control (RBAC) to ensure users can only access data and functionalities pertinent to their roles, and network segmentation to mitigate risks of unauthorized access. Advertisers can only manage their own listings, Seekers have access to search and view adverts, Moderators can approve or reject submissions, and Administrators have comprehensive management capabilities. The principle of least privilege is implemented by granting users the minimum access necessary to perform their responsibilities, thereby reducing the risk of data exposure and privilege escalation. For example, a Seeker can only view and communicate about adverts, while an Administrator has full control over user accounts and content moderation functions. --- ## 4. System Architecture Analysis ### 4.1. Architectural Overview A cloud-hosted, geo-centric web and mobile platform with a layered architecture: public users access a SPA or mobile-optimised site via a CDN/WAF edge layer; requests pass through an API Gateway to Application Services (Auth/RBAC, Core API, Search/Geo engine, Moderation pipeline, Messaging, Notifications, Payments). Application services persist data to a structured relational database for adverts/users, a search index for geo/filters, and object storage for media; audit logs and analytics stream to a logging/monitoring tier. Automated moderation (heuristics/ML) and human moderator UIs enforce content safety. External integrations include mapping APIs, email/push providers, and a PCI-compliant payment gateway. Strong privacy controls (approximate locations, email domain verification, PII encryption, consent management) and role-based access protect data and operations. ### 4.2. Architecture Diagram <style> svg { width: 100% !important; max-width: 100% !important; } .nodeLabel { white-space: normal !important; } </style> ```{mermaid} %%{init: {'theme':'dark'}}%% graph TB subgraph "Users" UserWeb[End Users Web/Mobile] AdminUser[Admins Moderators] end subgraph "Edge Layer" CDN[CDN & WAF] APIGW[API Gateway & Rate Limiter] end subgraph "Frontend Layer" FE[Web App SPA & Mobile UI] AdminUI[Admin Moderator UI] end subgraph "Application Services" Auth[Auth Service & RBAC] CoreAPI[Core API Services] SearchSvc[Search & Geo Engine] Moderation[Moderation Pipeline ML & Rules] Messaging[In-App Messaging] Notifs[Notifications Service] Billing[Payments & Billing Service] Analytics[Analytics & Reporting] end subgraph "Data Layer" DB[Relational DB Users/Adverts] ObjStore[Object Storage Media] Index[Search Index & Geohash] Logs[Audit Logging & SIEM] end subgraph "External Services" Maps[Maps API Mapbox/Google] Email[Email Service Provider] Push[Push Notification Provider] PaymentGW[PCI-DSS Payment Gateway] end UserWeb --> CDN --> FE --> APIGW --> Auth AdminUser --> CDN --> AdminUI --> APIGW --> Auth APIGW --> CoreAPI CoreAPI --> DB CoreAPI --> ObjStore CoreAPI --> Index CoreAPI --> Messaging CoreAPI --> Notifs CoreAPI --> Moderation CoreAPI --> Billing Moderation --> Logs Messaging --> DB Messaging --> Logs Notifs --> Email Notifs --> Push Billing --> PaymentGW SearchSvc --> Index SearchSvc --> CoreAPI CoreAPI --> Analytics Analytics --> Logs CoreAPI --> Maps Maps --> ExternalServices[Maps API Proxy] Email --> ExternalServices Push --> ExternalServices PaymentGW --> ExternalServices ``` ### 4.3. Component Breakdown | Component | Responsibility | Security Criticality | External Dependencies | |-----------|----------------|---------------------|----------------------| | Frontend Layer | Serve the SPA and mobile-optimised UI fo... | Medium | CDN/WAF, Maps API | | Edge Layer | CDN and Web Application Firewall to prot... | High | Cloud CDN provider, WAF/Rate-limiting service | | Application Services | Core business logic: authentication & RB... | Critical | ML/Moderation tooling (optional), Timeseries/analytics tools | | Data Storage | Persistent storage for relational data (... | Critical | Cloud-managed RDBMS, Cloud object storage | | External Services | Third-party integrations: maps for visua... | High | Mapbox/Google Maps, SendGrid/Mailgun or similar | | Admin & Moderation | Tools and UIs for moderators and admins ... | High | Identity provider for admin SSO, Audit logging/SIEM | | Notifications & Messaging | In-app mediated messaging between users,... | High | Email provider, Push provider | | Payments & Billing | Manage subscriptions, one-off purchases,... | Critical | PCI-DSS Payment Gateway (Stripe/Adyen), Tax/VAT services (optional) | ### 4.4. Data Flow Analysis Users interact via web/mobile UI which is served through a CDN/WAF. Client requests pass the API Gateway where authentication and rate-limiting occur. Authenticated requests reach Core APIs which validate input, invoke moderation checks (automated ML heuristics) and persist adverts, user profiles and room entities to the relational DB; media is uploaded to object storage and indexed into the search index (geohash/obfuscated coordinates). Search queries query the Search Index and may call geospatial services to cluster results; approximate locations are computed via geohash or centroid obfuscation before returning results to clients. Messaging is mediated by Messaging Service, storing encrypted message logs in DB and forwarding notifications to Notification Service which dispatches via email/push providers. Billing interacts with the Payment Gateway using tokenized card data; transaction metadata and audit logs are stored in DB and immutable logs. Moderation results and admin actions are logged to the audit/SIEM pipeline for retention and compliance. Data transformations include PII encryption at rest, location obfuscation, content scanning/enrichment, and payment tokenization. ### 4.5. Attack Surface Analysis Primary entry points: Web/Mobile UI and Public APIs (High risk) — exposure to account takeover, XSS, CSRF, injection and abuse; mitigations: strong authentication (MFA opt-in), input validation, CSP, WAF, rate limiting and session management. Authentication endpoints (High) — risk of brute-force and credential stuffing; mitigations: password policies, MFA, anomaly detection, account lockouts, email domain checks for advertiser onboarding. File uploads/media (Medium) — risk of malware and PII leaks; mitigations: virus scanning, size/type restrictions, storage isolation, signed URLs and metadata stripping. Messaging and moderated content endpoints (High) — risk of PII leakage, harassment and phishing; mitigations: content scanning, profanity/ML filters, human moderation queue, retention and redaction policies. Search and geo APIs (Medium) — risk of data inference and scraping to discover exact addresses; mitigations: approximate geohash, rate limits, API quotas, per-request obfuscation. Payment integration (High) — PCI exposure if misconfigured; mitigations: use tokenization via PCI-compliant gateway, do not store raw card data, secure webhooks and signed callbacks. Third-party integrations (Maps/Email/Push) (Medium) — supply chain risk and data leakage; mitigations: encrypted transit, minimal scopes, contractual DPAs and monitoring. Admin/moderator UIs (High) — privileged abuse or account compromise; mitigations: SSO, strong MFA, IP restrictions, session monitoring and immutable audit logs. Logging and analytics endpoints (Medium) — risk of sensitive data in logs; mitigations: PII redaction, access controls and log encryption. Overall, major risks concentrate on authentication, moderation, payments, and data exfiltration; the defensive architecture uses layered controls (edge WAF, gateway auth, service mTLS, encryption, RBAC, monitoring) and operational controls (incident response, retention policies, privacy/consent workflows). --- ## 5. Threat Modeling This section presents a comprehensive threat analysis of the system architecture and functional requirements. Threat modeling systematically identifies potential security vulnerabilities and attack vectors, enabling proactive risk mitigation through the application of appropriate security controls. ### 5.1. Threat Modeling Methodology This analysis employs the **STRIDE** threat modeling methodology, a systematic framework developed by Microsoft for identifying security threats across six categories: - **Spoofing Identity**: Threats involving impersonation of users or systems - **Tampering with Data**: Threats involving unauthorized modification of data or system components - **Repudiation**: Threats where users deny performing actions (lack of non-repudiation) - **Information Disclosure**: Threats involving unauthorized access to sensitive information - **Denial of Service**: Threats causing disruption or unavailability of system services - **Elevation of Privilege**: Threats allowing unauthorized access to privileged functions For each identified threat, the analysis evaluates **likelihood** (attack complexity and exposure) and **impact** (potential damage to confidentiality, integrity, or availability) to determine overall **risk level**. The methodology ensures comprehensive coverage of security concerns across all system components and interfaces. ### 5.2. Threat Analysis and Risk Assessment #### 5.2.1. Threat Overview The following table provides a quick reference of all identified threats. Detailed analysis including descriptions, mitigation strategies, and residual risk assessment (where available) is provided in the section below. | Threat ID | Component | Category | Risk Level | Likelihood | Impact | |-----------|-----------|----------|------------|-----------|--------| | THR-001 | Frontend Layer | Information Disclosure | Critical | High | High | | THR-006 | Application Services (Auth/RBAC) | Spoofing | Critical | High | High | | THR-002 | Frontend Layer | Tampering | High | High | Medium | | THR-004 | Edge Layer (CDN/WAF/API Gateway) | Denial of Service | High | Medium | High | | THR-005 | Edge Layer (API Gateway) | Spoofing | High | Medium | High | | THR-007 | Application Services (Auth/RBAC) | Elevation of Privilege | High | Medium | High | | THR-008 | Application Services (Core API/Search/Geo) | Information Disclosure | High | Medium | High | | THR-009 | Application Services (Moderation Pipeline) | Tampering | High | High | Medium | | THR-010 | Application Services (Messaging) | Information Disclosure | High | Medium | High | | THR-012 | Data Storage (Relational DB / Search Index) | Information Disclosure | High | Medium | High | | THR-015 | External Services (Payment Gateway) | Tampering | High | Medium | High | | THR-017 | Admin & Moderation | Elevation of Privilege | High | Medium | High | | THR-019 | Notifications & Messaging (In-app) | Denial of Service | High | High | Medium | | THR-021 | External Services (Email Provider) | Information Disclosure | High | Low | High | | THR-022 | Data Storage (Backups & Logs) | Information Disclosure | High | Medium | High | | THR-023 | Frontend / Edge (CDN) | Information Disclosure | High | Low | High | | THR-024 | Application Services / API | Tampering | High | Medium | High | | THR-027 | External Services (Third-party Integrations overall) | Information Disclosure | High | Medium | High | | THR-029 | Infrastructure / Cloud | Tampering | High | Medium | High | | THR-003 | Frontend Layer | Spoofing | Medium | Medium | Medium | | THR-011 | Notifications & Messaging (Email/Push Providers) | Information Disclosure | Medium | Medium | Medium | | THR-013 | Data Storage (Object Storage for Media) | Information Disclosure | Medium | Medium | Medium | | THR-014 | External Services (Maps API) | Information Disclosure | Medium | Medium | Medium | | THR-016 | Payments & Billing | Repudiation | Medium | Medium | Medium | | THR-018 | Admin & Moderation | Repudiation | Medium | Medium | Medium | | THR-020 | Application Services (Search/Geo) | Tampering | Medium | Medium | Medium | | THR-025 | Application Services (API) | Spoofing | Medium | Medium | Medium | | THR-026 | Payments & Billing | Repudiation | Medium | Low | Medium | | THR-028 | Platform-wide (Account Creation & Email Domain Filtering) | Spoofing | Medium | Medium | Medium | | THR-030 | Platform-wide (Search & Saved Searches / Alerts) | Information Disclosure | Medium | Low | Medium | **Total Threats Identified:** 30 #### 5.2.2. Detailed Threat Analysis This section provides comprehensive analysis of each identified threat, including descriptions, mitigation strategies, and residual risk assessment (where controls have been evaluated). Threats are organized by risk level for prioritized review. ##### Critical Risk Threats **THR-001** - Frontend Layer - **Category:** Information Disclosure - **Likelihood:** High | **Impact:** High - **Initial Risk Level:** Critical - **Description:** Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content, favourites, or saved searches causing session token theft, account takeover, or exfiltration of PII from pages rendered in other users' browsers. - **Mitigation Strategy:** Apply strict output encoding/escaping for all user content, use a secure templating engine, implement Content Security Policy (CSP) restricting script sources, sanitize HTML with a safe whitelist or disallow HTML, mark session cookies HttpOnly and SameSite=strict; conduct automated and manual security testing (SAST/DAST). - **Controls Applied:** CSP, Input Validation, Output Encoding, HttpOnly/SameSite Cookies, SAST/DAST - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-006** - Application Services (Auth/RBAC) - **Category:** Spoofing - **Likelihood:** High | **Impact:** High - **Initial Risk Level:** Critical - **Description:** Credential stuffing, weak password reuse, or brute-force attacks leading to account takeover for advertisers or moderators. Email domain filtering for free-tier may be bypassed using disposable or compromised university addresses. - **Mitigation Strategy:** Implement rate-limited login attempts, account lockouts with progressive delays, MFA (mandatory for moderators/admins and encouraged for advertisers), password strength policy, monitor for credential stuffing via IP reputation and breached-password checks; verify university domain via domain MX checks and time-limited email verification tokens. - **Controls Applied:** MFA, Rate Limiting, Breached Password Checks, Email Domain Verification - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review ##### High Risk Threats **THR-002** - Frontend Layer - **Category:** Tampering - **Likelihood:** High | **Impact:** Medium - **Initial Risk Level:** High - **Description:** Client-side manipulation of UI (e.g., modifying JS to change advert metadata, prices, or display premium features) and submitting forged requests that rely on client-side checks (price, entitlements). - **Mitigation Strategy:** Enforce server-side authorization and validation for all business-critical operations (price changes, entitlement checks). Sign client-visible configuration where needed, validate inputs on server, and log suspicious client-side anomalies. - **Controls Applied:** Server-side Authorization, Request Validation, Integrity Checks - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-004** - Edge Layer (CDN/WAF/API Gateway) - **Category:** Denial of Service - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Layer 7 volumetric or application-layer DDoS targeting search, messaging, or advert submission endpoints to degrade availability and impact revenue and user confidence. - **Mitigation Strategy:** Use CDN + WAF with adaptive rate-limiting and geo-blocking, API Gateway throttling per IP and per-account, autoscaling backend, CAPTCHA for suspicious flows (advert creation), traffic anomaly detection and scrubbing service. - **Controls Applied:** WAF, Rate Limiting, Autoscaling, DDoS Mitigation Service - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-005** - Edge Layer (API Gateway) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Replay attacks or token theft in transit due to inadequate transport security or poor token handling (long-lived tokens, insecure storage on client) leading to account hijacking. - **Mitigation Strategy:** Enforce TLS 1.2+/HSTS, short-lived access tokens with refresh tokens stored securely, require token binding if possible, use OAuth 2.0 best practices, revoke tokens on suspicious activity, secure local storage (avoid persistent tokens in localStorage), implement device/session fingerprinting and MFA for sensitive actions. - **Controls Applied:** TLS, OAuth2, Short-lived Tokens, MFA - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-007** - Application Services (Auth/RBAC) - **Category:** Elevation of Privilege - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Broken access control allowing privilege escalation (e.g., seeker modifies request to set 'role=moderator' or uses API endpoints reserved for admin to approve adverts). - **Mitigation Strategy:** Enforce server-side RBAC checks for every sensitive endpoint, implement deny-by-default ACLs, use centralized authorization library, detailed audit logging of role changes, review admin endpoints manually and require MFA/SSO for admin actions. - **Controls Applied:** RBAC, Centralized Authorization, Admin MFA/SSO, Audit Logging - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-008** - Application Services (Core API/Search/Geo) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Exposure of exact addresses or PII via search index or API responses (e.g., detailed coordinates leaked in map tile queries or in metadata exposed in API), undermining privacy requirement of approximate locations. - **Mitigation Strategy:** Implement server-side fuzzing/geo-obfuscation before storing/searching; strip exact coordinates from public search results, only store precise addresses encrypted and available to authorized parties, review third-party map integrations so they only receive approximate coordinates, log and monitor access to precise location fields. - **Controls Applied:** Field-level Encryption, Geo-obfuscation, Least Privilege Access, Third-party Data Minimization - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-009** - Application Services (Moderation Pipeline) - **Category:** Tampering - **Likelihood:** High | **Impact:** Medium - **Initial Risk Level:** High - **Description:** Adversarial content engineered to bypass automated moderation (image/text obfuscation, alternate language, unicode tricks) leading to publication of spam, scams, or malicious adverts. - **Mitigation Strategy:** Use layered moderation: ML heuristics + deterministic rules + human review for flagged or high-risk adverts; adversarial testing of moderation models; limit feature exposure for new/low-reputation advertisers; rate-limit advert creation. - **Controls Applied:** Automated Moderation, Human-in-the-loop, Adversarial Testing, Rate Limiting - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-010** - Application Services (Messaging) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** In-app moderated messaging used to exchange PII; messages stored in DB and in transit may be exposed due to weak encryption, improper RBAC, or logging of message bodies to analytics systems. - **Mitigation Strategy:** Encrypt messages at rest with KMS-managed keys, enforce TLS in transit, restrict access to message stores to smallest set of service accounts, redact PII in analytics pipelines, provide ephemeral message retention policies and user-controlled deletion, log only metadata not message contents. - **Controls Applied:** TLS, At-rest Encryption (KMS), RBAC, PII Redaction - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-012** - Data Storage (Relational DB / Search Index) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Unauthorized access to backups, snapshots, or misconfigured search index (Elasticsearch/OpenSearch) exposing full dataset including PII or sensitive adverts. - **Mitigation Strategy:** Enforce network-level access controls (VPC, private endpoints), enable authentication and TLS on search services, encrypt backups at rest, rotate access keys, restrict snapshot exports, and monitor/access alerts for unusual data exports. - **Controls Applied:** Network ACLs, Encryption at Rest, Access Controls, Monitoring/Alerts - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-015** - External Services (Payment Gateway) - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Payment flow manipulation or token interception causing fraudulent premium listings, subscription status manipulation, or chargeback/fraud against the platform. - **Mitigation Strategy:** Use PCI-compliant gateway with tokenization (never store raw card data), validate webhooks with signatures, verify payment notification origins, reconcile subscription state server-side, implement fraud detection and anomaly monitoring, require 3DS where supported. - **Controls Applied:** PCI-DSS Payment Gateway, Webhook Signing, Server-side Reconciliation, Fraud Detection - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-017** - Admin & Moderation - **Category:** Elevation of Privilege - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Compromise of admin/moderator accounts via phishing or weak SSO config leading to mass approval of malicious adverts, deletion or tampering with audit logs, or user bans. - **Mitigation Strategy:** Use strong SSO with MFA, enforce least privilege for moderator roles (separation of duties), require justification and second approval for bulk actions, record all admin actions to immutable audit logs, and monitor for anomalous admin activity. - **Controls Applied:** SSO with MFA, Least Privilege, Immutable Audit Logs, Two-person Review for Critical Actions - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-019** - Notifications & Messaging (In-app) - **Category:** Denial of Service - **Likelihood:** High | **Impact:** Medium - **Initial Risk Level:** High - **Description:** Messaging system spam or automated bots overwhelm a user's inbox or notification system causing resource exhaustion and poor UX; attackers may use messaging to send harmful links. - **Mitigation Strategy:** Rate-limit message sending per account/IP, implement reputation scoring for senders, CAPTCHAs on account actions, automated content filtering, allow users to block/report senders, throttle notifications and use backpressure in queueing system. - **Controls Applied:** Rate Limiting, Reputation System, CAPTCHA, Content Filtering - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-021** - External Services (Email Provider) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** High - **Initial Risk Level:** High - **Description:** Compromise or misconfiguration at the email provider leading to leakage of verification emails, digests, or password resets enabling account takeover or exposure of PII. - **Mitigation Strategy:** Use reputable ESP with secure contracts, enable TLS and DKIM/SPF/DMARC, minimize sensitive data in emails, send reset links that expire quickly, monitor ESP security advisories, and have incident response plan for ESP compromise. - **Controls Applied:** TLS, DKIM/SPF/DMARC, ESP SLA Review - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-022** - Data Storage (Backups & Logs) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Backups or audit logs containing historic PII retained longer than necessary, or accessible by excessive staff, leading to compliance violations (GDPR) and data breach risks. - **Mitigation Strategy:** Apply data retention policies and automated deletion, anonymize/pseudonymize PII where possible, restrict access to backups via IAM, encrypt backups, and periodically audit access to retention stores. - **Controls Applied:** Data Retention Policy, Encryption, Access Controls - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-023** - Frontend / Edge (CDN) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** High - **Initial Risk Level:** High - **Description:** Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pages cached publicly) exposing PII or private adverts to other users. - **Mitigation Strategy:** Use cache-control headers to prevent caching of personalized content, vary cache on headers appropriately, use CDN configuration to strip sensitive cookies/headers, and test CDN caching rules for unintended caching. - **Controls Applied:** Cache-Control Headers, CDN Configuration Review - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-024** - Application Services / API - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Injection attacks (SQL injection or NoSQL injection) via poorly validated advert fields or search parameters allowing data tampering, unauthorized data access, or remote code execution via unsafe ORM usage. - **Mitigation Strategy:** Use parameterized queries/ORM safe APIs, validate and constrain inputs (length/format), ORM prepared statements, adopt least-privilege DB accounts, run regular SAST/DAST and DB access monitoring, and protect admin endpoints behind stricter controls. - **Controls Applied:** Parameterized Queries, Input Validation, SAST/DAST - **Control Effectiveness:** High - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-027** - External Services (Third-party Integrations overall) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Over-sharing of PII to third-party analytics, logging, or ML moderation providers (sending full message bodies or exact addresses) creating compliance and privacy risk. - **Mitigation Strategy:** Data minimization: pseudonymize or aggregate before sending, use contracts and DPA with providers, vet security posture of providers, encrypt data in transit and at rest, and implement strict access controls on provider integrations. - **Controls Applied:** Data Minimization, DPA/Contracts, Pseudonymization - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review **THR-029** - Infrastructure / Cloud - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Initial Risk Level:** High - **Description:** Cloud misconfigurations (open management ports, overly permissive IAM roles, publicly exposed DB or storage) allowing attackers to access or modify data and resources. - **Mitigation Strategy:** Implement IaC with security scanning, enforce least-privilege IAM, use VPC/private endpoints, rotate credentials, use cloud provider security posture management (CSPM), run periodic pen tests and configuration audits, and enable multi-account separation for prod/staging. - **Controls Applied:** Least-Privilege IAM, CSPM, IaC Scanning, Network Segmentation - **Control Effectiveness:** Medium - **Residual Risk Level:** Medium - **Status:** ⚠️ Requires Review ##### Medium Risk Threats **THR-003** - Frontend Layer - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** UI-level phishing via malicious adverts or profiles that mimic platform branding to trick users into revealing credentials or off-platform contact details. - **Mitigation Strategy:** Restrict HTML/branding in adverts, enforce a platform watermark and verified-badge UI for verified advertisers, run automated moderation for suspicious branding, user education and reporting flow, and block off-platform contact until verification. - **Controls Applied:** Automated Moderation, Verified Badges, User Reporting - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ⚠️ Requires Review **THR-011** - Notifications & Messaging (Email/Push Providers) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Sensitive information leaked via email digests or push notifications (e.g., full advert addresses, private messages) or email interception due to misconfigured email provider templates exposing PII. - **Mitigation Strategy:** Limit content in notifications to non-sensitive summaries, avoid including PII or exact location in emails/pushes, use secure provider configurations (TLS for SMTP, signed DKIM/SPF), allow users to opt-out of email content sharing, and review templates for accidental leakage. - **Controls Applied:** Template Review, TLS for Email, Notification Content Policy - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-013** - Data Storage (Object Storage for Media) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Publicly accessible S3/Blob containers containing photos that include metadata or people could be exposed due to incorrect ACLs or predictable object URLs. - **Mitigation Strategy:** Use private buckets with signed, time-limited URLs for media access, strip EXIF/GPS metadata from uploaded photos, scan uploads for sensitive content, enforce upload size/content checks, and set least-privilege IAM policies for storage access. - **Controls Applied:** Signed URLs, EXIF Stripping, Private Buckets, IAM Policies - **Control Effectiveness:** High - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-014** - External Services (Maps API) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Third-party map provider logs or telemetry reveal approximate queries or leak location metadata (e.g., passing exact coords), or attacker abuses API keys embedded in frontend to query map endpoints for data enumeration. - **Mitigation Strategy:** Send only obfuscated/approximate coordinates to map provider, restrict API keys via referer/IP restrictions, avoid embedding privileged keys in client, use server-side map proxy for sensitive queries, review provider's privacy SLA. - **Controls Applied:** API Key Restriction, Server-side Proxy, Coordinate Obfuscation - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-016** - Payments & Billing - **Category:** Repudiation - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Advertisers dispute charges or claim service not delivered; lack of reliable invoice/transaction audit trail hinders dispute resolution and may lead to financial loss. - **Mitigation Strategy:** Maintain tamper-evident audit logs for billing events, store payment tokenization metadata, send receipts with transaction IDs, enable immutable logs in SIEM, and retain reconciliation records per compliance retention policies. - **Controls Applied:** Immutable Audit Logs, Receipt/Invoice Records, SIEM - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-018** - Admin & Moderation - **Category:** Repudiation - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Insufficient or tamperable audit logs allowing admins/moderators to deny or hide actions (e.g., disabling adverts without reason), impacting incident response and compliance. - **Mitigation Strategy:** Use append-only, write-once audit logging (cloud-native immutability), forward logs to SIEM with restricted access, implement logging integrity checks, and enforce log retention/rotation policies for compliance. - **Controls Applied:** Immutable Logging, SIEM, RBAC on Logs - **Control Effectiveness:** High - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-020** - Application Services (Search/Geo) - **Category:** Tampering - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Search index poisoning or malicious adverts crafted to manipulate search ranking (e.g., SEO spam, repeated adverts to surface malicious listings), reducing quality and user trust. - **Mitigation Strategy:** Rate-limit advert creation, use deduplication checks, reputation-based ranking and human review for new advertisers, monitor ranking changes, and use anomaly detection in search metrics. - **Controls Applied:** Rate Limiting, Reputation-based Ranking, Index Integrity Checks - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-025** - Application Services (API) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** API key leakage or abuse (e.g., frontend-embedded keys used to query private endpoints or enumerate adverts), enabling attackers to harvest data or bypass quotas. - **Mitigation Strategy:** Never embed privileged keys in frontend, restrict keys by origin/IP and scope, rotate keys regularly, monitor key usage and set quotas, and require server-side calls for privileged operations. - **Controls Applied:** Key Rotation, Key Restrictions, Monitoring - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-026** - Payments & Billing - **Category:** Repudiation - **Likelihood:** Low | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Lack of immutable proof for subscription entitlement changes leads to disputes where advertisers claim upgrades/downgrades were not applied correctly or were fraudulent. - **Mitigation Strategy:** Record subscription lifecycle events immutably with timestamps, require server-side confirmation flows for entitlements, keep audit trails tied to payment gateway transaction IDs, and notify users on entitlement changes. - **Controls Applied:** Immutable Audit Trail, Server-side Entitlement Enforcement - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-028** - Platform-wide (Account Creation & Email Domain Filtering) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Bypass of email-domain verification for free-tier advertisers using disposable university-like addresses or compromised student mailbox leading to fraudulent adverts. - **Mitigation Strategy:** Perform MX record checks and restrict to known university domains list, implement additional checks (SAML/IdP integration with select institutions), manual/automated scrutiny for new advertiser accounts, rate-limit new accounts, and use reputation scoring before granting free-tier privileges. - **Controls Applied:** MX Verification, Known Domain Allowlist, SAML/Institutional SSO - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **THR-030** - Platform-wide (Search & Saved Searches / Alerts) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** Medium - **Initial Risk Level:** Medium - **Description:** Saved searches and alert digest emails could be inferred by attackers to profile a user's activity or to stalk users (e.g., frequent queries for a person's name or location patterns). - **Mitigation Strategy:** Protect saved search metadata with proper ACLs, encrypt saved filters in DB if sensitive, allow users to opt-out of instant alerts, aggregate digest emails, and rate-limit alerts per user to prevent metadata leakage. - **Controls Applied:** ACLs, Encryption of User Metadata, User Privacy Controls - **Control Effectiveness:** Medium - **Residual Risk Level:** Low - **Status:** ✅ Accepted **Risk Reduction Summary:** - **Critical Risk Reduction:** 2 threats reduced from Critical to lower levels - **High Risk Reduction:** 17 threats reduced from High to lower levels - **Residual Risk Distribution:** 0 threats remain at Critical/High level ### 5.3. Risk Summary The most critical threats are account compromise (THR-006), XSS and client-side attacks (THR-001), exposure of PII/location data via storage or third-party integrations (THR-008, THR-012, THR-027), and payment-related fraud or token manipulation (THR-015). Attackers can enter via credential stuffing, injection vectors, third-party API key leakage, misconfigured cloud services, or by exploiting moderation gaps. Availability risks (DDoS against search/messaging — THR-004) also present high business impact. Priority controls: enforce strong authentication/MFA and centralized RBAC for admin functions; server-side input validation and parameterized queries; encryption-at-rest and field-level encryption for PII; strict handling of geolocation (server-side obfuscation and minimal sharing with map providers); implement WAF and API Gateway rate-limiting; use PCI-compliant payment tokenization and webhook verification; use layered moderation (ML + human review) and content sanitization; and operational controls such as least-privilege IAM, CSPM, immutible audit logging, and incident detection/response with SIEM. Overall risk posture is moderate-high: multiple high-impact vectors exist but can be materially reduced by implementing the above prioritized controls. Immediate attention should focus on account and admin protection (MFA, SSO hardening, RBAC), preventing PII leakage (encryption, obfuscation, third-party minimization), secure payment integration, and robust moderation and anti-abuse measures. --- ## 6. Multi-Standard Security Requirements Mapping This section maps each functional requirement to specific security controls from multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. This multi-standard approach provides comprehensive coverage across application-level, enterprise-level, and organizational-level security domains: - **OWASP ASVS**: Application-level security controls (code, APIs, authentication, session management) - **NIST SP 800-53**: Enterprise security controls (governance, risk management, incident response) - **ISO 27001**: Information security management controls (policies, procedures, organizational controls) Requirements are prioritized based on risk assessment and compliance needs, with controls selected from the most appropriate standard(s) for each requirement type. ### 6.1. Recommended ASVS Compliance Level **Recommended Level:** L2 **Level 2: Standard** Recommended for most production applications. Provides comprehensive security coverage suitable for applications handling sensitive data or operating in regulated environments. Includes controls for authentication, authorization, data protection, and secure communications. The recommendation considers factors such as: - Data sensitivity and classification levels - Regulatory and compliance requirements (GDPR, HIPAA, PCI-DSS, etc.) - Threat landscape and risk assessment from threat modeling - Business criticality and potential impact of security incidents All security controls referenced in this document align with this recommended compliance level. ### 6.2. Requirements Mapping This section maps each high-level requirement to specific security controls from multiple standards (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed descriptions, relevance explanations, and integration guidance. Controls are grouped by standard for clarity. #### 6.2.1. REQ-1: User registration and login with role assignment and secure authentication ##### OWASP ASVS Controls **V2.1.1** **Requirement:** Verify that user registration and login mechanisms require robust authentication, including secure password handling and account lifecycle management. **Relevance:** Covers secure authentication during registration and login, ensuring robust password practices. Aligns directly with role assignment by enforcing strong authentication before authorization decisions. **Integration Tips:** Implement password hashing with a modern algorithm (e.g., Argon2id, bcrypt) and enforce complexity and lockout policies. Ensure account lifecycle includes activation, lock, recovery workflows with secure tokens. **Verification Method:** Review auth flow design, inspect password storage configuration, and test registration/login including account lifecycle. **Level:** L1 | **Priority:** Critical **V4.1.1** **Requirement:** Verify that a role-based access control (RBAC) or attribute-based access control (ABAC) scheme is enforced at the application level for all protected resources. **Relevance:** Addresses role assignment and enforcement across resources, essential for separating user capabilities. Ensures authorization checks are centralized and consistent. **Integration Tips:** Define roles and permissions in a policy store and enforce checks server-side on every request. Use middleware/filters to guard endpoints and include role claims in access tokens. **Verification Method:** Policy review, code inspection of authorization middleware, and role-based access tests. **Level:** L1 | **Priority:** Critical ##### NIST SP 800-53 Controls **IA-2** **Requirement:** Identify and authenticate organizational users (and/or processes acting on behalf of users). **Relevance:** Ensures all users are uniquely identified and authenticated before accessing the system. Underpins secure login and session establishment. **Integration Tips:** Use unique user IDs, enforce strong authenticators, and bind sessions/tokens to authenticated identities. Log authentication attempts and outcomes. **Verification Method:** Inspect identity provider configuration, review auth logs, and perform positive/negative login tests. **Priority:** Critical ##### ISO 27001:2022 Controls **A.9.2.3** **Requirement:** The provisioning of user access rights shall be formalized, including assignment of access rights to all types of users for all systems and services. **Relevance:** Formalizes role assignment processes and approvals to prevent excessive privileges. Supports onboarding and changes in user roles. **Integration Tips:** Implement joiner-mover-leaver workflows with approvals and documented RBAC matrices. Periodically review access rights and automate provisioning via IAM. **Verification Method:** Review access provisioning SOPs, sampling of access requests, and RBAC review records. **Priority:** High #### 6.2.2. REQ-2: Email domain verification and tier-based access controls (free vs paid advertisers) ##### OWASP ASVS Controls **V2.2.3** **Requirement:** Verify that the application verifies the ownership of an email address or phone number during registration and prior to activation. **Relevance:** Directly maps to verifying email ownership before granting access or features. Prevents fake or unverified accounts from accessing tiers. **Integration Tips:** Send signed, single-use, time-limited verification links and require completion before enabling account. Track verification status and block feature access until verified. **Verification Method:** Functional tests of email verification flow and review of token expiry/one-time use implementation. **Level:** L2 | **Priority:** High **V4.2.1** **Requirement:** Verify that access controls enforce authorization decisions based on the authenticated user's role or attributes. **Relevance:** Supports tier-based access by enforcing decisions tied to attributes such as subscription status. Ensures paid features are limited to authorized users. **Integration Tips:** Model tier as user attributes/claims and enforce checks in controllers/services. Use policy-based authorization to centralize logic. **Verification Method:** Review authorization policies and test scenarios for free vs paid users. **Level:** L1 | **Priority:** Critical ##### NIST SP 800-53 Controls **AC-2** **Requirement:** Manage information system accounts, including establishing, activating, modifying, disabling, and removing accounts. **Relevance:** Provides governance for account status changes tied to subscription lifecycle (e.g., downgrades, suspensions). Ensures only active, verified accounts access tiers. **Integration Tips:** Automate activation post-verification, suspend on non-payment, and remove access on subscription end. Maintain audit trails for account state changes. **Verification Method:** Review account lifecycle automation and audit logs for state transitions. **Priority:** High ##### ISO 27001:2022 Controls **A.9.1.2** **Requirement:** Users shall only be provided with access to the network and network services that they have been specifically authorized to use. **Relevance:** Supports restricting platform services to the appropriate tier. Ensures least privilege across service boundaries. **Integration Tips:** Segment paid-tier services and enforce service-level authorization checks. Configure API gateways to evaluate tier claims. **Verification Method:** Review service access configurations and test unauthorized access attempts. **Priority:** Medium #### 6.2.3. REQ-3: User profile management with verifiable contact display options ##### OWASP ASVS Controls **V1.4.3** **Requirement:** Verify that the application collects and processes only the minimum amount of personal data necessary and provides users control over data sharing. **Relevance:** Ensures profiles collect minimal data and provide controls for showing/hiding verified contacts. Reduces exposure and supports user choice. **Integration Tips:** Design profile fields as optional where possible, and include per-field visibility toggles. Avoid storing unnecessary contact data. **Verification Method:** Design review and UX testing of privacy controls; data inventory check for minimization. **Level:** L2 | **Priority:** High **V9.1.1** **Requirement:** Verify that the application protects personal data and supports data minimization consistent with privacy requirements. **Relevance:** Classifies profile contact data as personal and enforces appropriate protections. Aligns with display options and minimization. **Integration Tips:** Mark contact fields as sensitive and apply encryption and access restrictions. Ensure logs do not expose contact details. **Verification Method:** Review data classification and storage protections; check logs for PII leakage. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **AC-6** **Requirement:** Employ the principle of least privilege, allowing only authorized access for users (and processes acting on behalf of users) which are necessary to accomplish assigned tasks. **Relevance:** Restricts who can view or modify profile and contact data. Supports controlled display options and backend enforcement. **Integration Tips:** Enforce per-user and per-field access checks in APIs. Limit support/admin tools to read-only unless explicitly approved. **Verification Method:** Access tests for different roles and review of API authorization rules. **Priority:** High ##### ISO 27001:2022 Controls **A.18.1.4** **Requirement:** Privacy and protection of personally identifiable information shall be ensured as required in relevant legislation and regulation. **Relevance:** PII in user profiles and contact details must be protected and processed lawfully. Governs how contact info is displayed and shared. **Integration Tips:** Document lawful bases, implement consent where needed, and restrict display of PII via user-controlled settings. Apply masking by default. **Verification Method:** Review privacy documentation, data flows, and UI settings for PII exposure. **Priority:** Critical #### 6.2.4. REQ-4: Advert creation, edit, delete lifecycle with support for multi-room properties ##### OWASP ASVS Controls **V4.2.2** **Requirement:** Verify that users can only create, read, update, or delete resources that they own or are authorized to access. **Relevance:** Ensures advert CRUD actions are limited to owners or authorized roles. Prevents unauthorized modifications across listings. **Integration Tips:** Implement ownership checks using resource IDs and subject claims. Enforce at service layer and re-check at data access layer. **Verification Method:** Unit/integration tests for owner vs non-owner scenarios; code review of authorization checks. **Level:** L1 | **Priority:** Critical **V5.1.3** **Requirement:** Verify that all inputs are validated using positive validation (allow lists) for expected data types, ranges, and formats. **Relevance:** Advert fields (e.g., room counts, prices) need strict validation to prevent injection and logic abuse. Supports data integrity. **Integration Tips:** Use server-side schema validation for all advert inputs and normalize data. Sanitize rich text fields and file uploads. **Verification Method:** Review validation schemas and fuzz test inputs; check that invalid data is rejected. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **AC-3** **Requirement:** Enforce approved authorizations for logical access to information and system resources. **Relevance:** General enforcement mechanism to apply policy for advert lifecycle operations. Supports multi-room record integrity. **Integration Tips:** Centralize policy enforcement and ensure database queries include ownership constraints. Use deny-by-default posture. **Verification Method:** Policy review and data-layer query inspection for authorization predicates. **Priority:** High ##### ISO 27001:2022 Controls **A.14.2.5** **Requirement:** Security testing shall be carried out during development. **Relevance:** Ensures advert lifecycle features undergo security testing to catch authorization and validation gaps. Reduces deployment risk. **Integration Tips:** Include security test cases in CI for CRUD operations and access control. Perform code reviews focusing on ownership checks. **Verification Method:** Evidence of CI security tests and review records. **Priority:** Medium #### 6.2.5. REQ-5: Automated and manual moderation workflow for adverts and content ##### OWASP ASVS Controls **V7.1.1** **Requirement:** Verify that all security-relevant events are logged, including authentication, authorization decisions, and administrative actions. **Relevance:** Moderation is an administrative function requiring comprehensive logging. Enables forensic review and dispute resolution. **Integration Tips:** Instrument moderation services to emit structured logs and centralize them. Protect logs with RBAC and integrity controls. **Verification Method:** Check logging configuration and attempt to access logs with different roles. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **AU-3** **Requirement:** Ensure that audit records contain information that establishes what events occurred, the sources of the events, and the outcomes of the events. **Relevance:** Moderation actions must be auditable to trace who approved/rejected content and why. Supports accountability in workflows. **Integration Tips:** Log moderation events with actor ID, object, action, reason, and outcome. Use immutable storage or WORM where feasible. **Verification Method:** Review audit log fields and sample records for completeness. **Priority:** High **AU-6** **Requirement:** Review and analyze information system audit records for indications of inappropriate or unusual activity and report findings. **Relevance:** Requires active analysis of moderation logs for abuse or errors. Supports both automated alerts and manual oversight. **Integration Tips:** Create dashboards for moderation KPIs and anomaly detection. Define escalation paths for suspicious patterns. **Verification Method:** Inspect SIEM dashboards and alert configurations for moderation events. **Priority:** Medium ##### ISO 27001:2022 Controls **A.12.4.1** **Requirement:** Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and regularly reviewed. **Relevance:** Mandates ongoing review of moderation-related logs to detect issues or abuse. Complements automated and manual workflows. **Integration Tips:** Establish review schedules and alerts for moderation anomalies (e.g., high rejection rate by a user). Document procedures. **Verification Method:** Review log review procedures and evidence of periodic reviews. **Priority:** Medium #### 6.2.6. REQ-6: Geo-centric search and filtered discovery with map visualisation (approximate locations) ##### OWASP ASVS Controls **V1.4.2** **Requirement:** Verify that the application limits collection and retention of location and other sensitive data to the minimum necessary. **Relevance:** Approximate locations reduce privacy risks in map visualisation. Control mandates limiting collection/retention of geodata. **Integration Tips:** Store coarse geohashes instead of exact coordinates and purge old location data per retention policy. Disable location logging by default. **Verification Method:** Review data model and retention jobs; verify only approximate location is exposed. **Level:** L2 | **Priority:** High **V9.4.1** **Requirement:** Verify that sensitive data such as geolocation is not exposed in logs or through APIs beyond what is necessary for business purposes. **Relevance:** Prevents leakage of exact locations via logs or APIs during geo search and filters. Aligns to privacy-by-design. **Integration Tips:** Mask or omit exact lat/long in API responses and redact in logs. Implement schema-level allowlists for fields. **Verification Method:** API response and log sampling to confirm no precise coordinates are present. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **PL-8** **Requirement:** Develop an information security architecture for the system that describes the requirements and approach to protect organizational information. **Relevance:** Ensures geo features are designed with security/privacy controls embedded. Guides architecture for map services and data flows. **Integration Tips:** Document data flows for geo queries, caching, and third-party maps. Include threat modeling for location privacy. **Verification Method:** Review security architecture documents and threat models covering geo components. **Priority:** Medium ##### ISO 27001:2022 Controls **A.18.1.5** **Requirement:** Cryptographic controls shall be used in compliance with all relevant agreements, legislation and regulations. **Relevance:** Map data transfer and storage may require cryptographic protections, especially for location data. Ensures compliant crypto usage. **Integration Tips:** Use TLS for map APIs and encrypt sensitive caches at rest. Maintain cipher suites in line with policy. **Verification Method:** Crypto configuration review and TLS scanning of map endpoints. **Priority:** Medium #### 6.2.7. REQ-7: Advanced filtering, saveable searches, and alerting (instant and daily digest) ##### OWASP ASVS Controls **V10.4.1** **Requirement:** Verify that the application enforces business logic with appropriate limits and thresholds (e.g., rate limits) to prevent abuse. **Relevance:** Alerting features can be abused for spam or resource exhaustion; rate limits mitigate abuse. Controls align with business logic enforcement. **Integration Tips:** Apply per-user and per-destination quotas for alerts and digests. Implement backoff and queue throttling. **Verification Method:** Review rate limit configurations and simulate high-frequency alert creation. **Level:** L2 | **Priority:** High **V5.4.3** **Requirement:** Verify that untrusted data is properly sanitized and output encoded to prevent injection in notifications and alerts. **Relevance:** Search filters and results may be reflected in notifications; encoding prevents injection in emails/push messages. **Integration Tips:** Template notifications with strict encoding and avoid HTML from users. Validate and sanitize saved search names/criteria. **Verification Method:** Review templates and perform injection tests in alert content. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **SI-4** **Requirement:** Monitor the information system to detect attacks and indicators of potential attacks. **Relevance:** Monitoring helps detect alerting abuse or anomalous filter activity. Supports operational security of alert pipelines. **Integration Tips:** Create alerts for unusual spikes in alert generation or delivery failures. Feed logs into SIEM for correlation. **Verification Method:** Check monitoring rules and SIEM dashboards for alerting subsystem. **Priority:** Medium ##### ISO 27001:2022 Controls **A.12.1.3** **Requirement:** The use of resources shall be monitored, tuned and projections made of future capacity requirements to ensure system performance. **Relevance:** Digest and alert jobs can impact capacity; capacity management ensures stability and prevents DoS-like conditions. **Integration Tips:** Track queue sizes and throughput; auto-scale workers. Schedule digests to spread load. **Verification Method:** Review capacity dashboards and auto-scaling policies. **Priority:** Low #### 6.2.8. REQ-8: Favourites/bookmarking and personalised saved-advert lists with organisation tools ##### OWASP ASVS Controls **V4.3.1** **Requirement:** Verify that users can only access their own records, such as personal lists, favorites, or bookmarks. **Relevance:** Directly addresses access isolation for saved lists and favorites. Prevents cross-user data exposure. **Integration Tips:** Enforce user-scoped queries at the data layer and use tenant/user IDs in keys. Add tests for IDOR. **Verification Method:** Conduct IDOR testing on list endpoints and inspect ORM scoping rules. **Level:** L1 | **Priority:** Critical **V9.3.1** **Requirement:** Verify that sensitive stored data is protected from unauthorized access and tampering. **Relevance:** Protects saved lists and notes from tampering and unauthorized reads, especially if containing personal annotations. **Integration Tips:** Use database-level encryption, strict ACLs, and integrity checks. Avoid exposing identifiers sequentially. **Verification Method:** Review storage encryption and access controls; test for tampering resistance. **Level:** L1 | **Priority:** Medium ##### NIST SP 800-53 Controls **AC-16** **Requirement:** Associate security attributes with information by information systems and enforce attribute-based policies. **Relevance:** Using attributes (owner, visibility) supports fine-grained control over lists and sharing options. Enhances policy enforcement. **Integration Tips:** Tag list records with owner and visibility attributes and enforce at query time. Log attribute changes. **Verification Method:** Review database schema and policy enforcement logic for attribute checks. **Priority:** High ##### ISO 27001:2022 Controls **A.9.4.1** **Requirement:** Access to information and application system functions shall be restricted in accordance with the access control policy. **Relevance:** Requires restricting list data and associated functions to authorized users only. Supports defined access policy. **Integration Tips:** Map list operations to policy rules; implement deny by default. Periodically review permissions. **Verification Method:** Policy review and functional testing of access restrictions. **Priority:** Medium #### 6.2.9. REQ-9: Secure in-app messaging between users with optional verified contact reveal ##### OWASP ASVS Controls **V9.2.1** **Requirement:** Verify that all sensitive communications are encrypted in transit using secure protocols. **Relevance:** In-app messaging contains sensitive content and must be protected in transit. Prevents eavesdropping and tampering. **Integration Tips:** Enforce TLS 1.2+ for APIs and websockets; use HSTS. Validate certificates and pin where appropriate. **Verification Method:** TLS configuration scan and packet inspection to confirm encryption. **Level:** L1 | **Priority:** Critical **V2.8.1** **Requirement:** Verify that re-authentication or step-up authentication is required before performing sensitive actions such as revealing personal contact details. **Relevance:** Optional contact reveal is a sensitive action that should require step-up checks. Reduces risk of unauthorized exposure. **Integration Tips:** Prompt for password/MFA re-check before revealing contact info. Use short-lived tokens to authorize the reveal action. **Verification Method:** Functional test of step-up flow and token expiry behavior. **Level:** L2 | **Priority:** High ##### NIST SP 800-53 Controls **SC-13** **Requirement:** Employ cryptographic mechanisms to prevent unauthorized disclosure of information and detect changes to information during transmission. **Relevance:** Mandates robust cryptographic protections for messaging channels. Supports integrity and confidentiality of messages. **Integration Tips:** Use authenticated encryption ciphersuites; consider message signing if end-to-end requirements exist. **Verification Method:** Review cipher suites and test integrity verification on message transport. **Priority:** High ##### ISO 27001:2022 Controls **A.13.2.3** **Requirement:** Information involved in electronic messaging shall be appropriately protected. **Relevance:** Establishes organizational requirements to safeguard messaging data at rest and in transit. Covers policies and controls. **Integration Tips:** Define retention limits, enable encryption at rest for message stores, and restrict admin access to message content. **Verification Method:** Policy review and storage configuration checks; access audit for admin views. **Priority:** Medium #### 6.2.10. REQ-10: Interactive map with clustering and approximate location display ##### OWASP ASVS Controls **V1.4.1** **Requirement:** Verify that privacy requirements such as data minimization and anonymization are addressed in the design. **Relevance:** Approximate location display should anonymize user locations. Ensures privacy considerations are built into map features. **Integration Tips:** Use aggregation/clustering thresholds and snap points to grids to avoid pinpointing exact addresses. Avoid storing raw coordinates in the client. **Verification Method:** Design review and UI tests to confirm only approximate positions are shown. **Level:** L1 | **Priority:** High **V5.3.1** **Requirement:** Verify that data rendered in the UI, including maps and visualizations, is properly encoded to prevent injection. **Relevance:** Map popups and labels may render user-supplied data; encoding prevents XSS in map visualizations. **Integration Tips:** Sanitize and encode all map label fields and disable HTML where possible. Use safe templating APIs. **Verification Method:** Dynamic application security testing for XSS in map components. **Level:** L1 | **Priority:** High ##### NIST SP 800-53 Controls **SC-7** **Requirement:** Monitor and control communications at the external boundary and key internal boundaries of the system. **Relevance:** External map tiles/APIs often cross system boundaries; boundary protection controls access and monitoring. **Integration Tips:** Route third-party map calls through controlled egress with allowlists and API keys vaulting. Monitor outbound traffic. **Verification Method:** Network configuration review and monitoring of egress to mapping services. **Priority:** Medium ##### ISO 27001:2022 Controls **A.14.2.1** **Requirement:** Rules for the development of software and systems shall be established and applied to developments within the organization. **Relevance:** Ensures secure coding and review standards apply to map components. Reduces vulnerabilities in interactive UIs. **Integration Tips:** Adopt secure coding guidelines for frontend visualization and perform code reviews. Include threat modeling for map features. **Verification Method:** Check SDLC policy adherence and code review records for map modules. **Priority:** Low #### 6.2.11. REQ-11: Notifications system for adverts, messages and moderation status ##### OWASP ASVS Controls **V10.4.2** **Requirement:** Verify that the application enforces anti-automation controls such as rate limiting for notification-triggering actions. **Relevance:** Notifications can be abused for spamming or DoS; rate limiting protects system and users. Critical for user-triggered alerts. **Integration Tips:** Throttle per user and per recipient address; implement CAPTCHA/anti-automation on high-risk endpoints. **Verification Method:** Review rate limiting middleware configuration and attempt burst notification generation. **Level:** L2 | **Priority:** High **V7.1.2** **Requirement:** Verify that logging includes sufficient detail to identify the subject, action, object, timestamp, and outcome for security-relevant events. **Relevance:** Notification events, especially moderation status changes, need detailed logs for troubleshooting and audits. **Integration Tips:** Ensure structured logging of notification sends, failures, and user actions with correlation IDs. **Verification Method:** Review sample logs for required fields and correlation. **Level:** L2 | **Priority:** Medium ##### NIST SP 800-53 Controls **SI-10** **Requirement:** Check the validity of information inputs. **Relevance:** Notification content and addresses must be validated to prevent injection or misrouting. Protects integrity of notifications. **Integration Tips:** Validate email/phone formats and sanitize message content before enqueue. Reject invalid payloads at API boundary. **Verification Method:** Input validation tests and code review of notification payload handling. **Priority:** High ##### ISO 27001:2022 Controls **A.12.4.3** **Requirement:** Administrator and operator activities shall be logged and the logs protected and regularly reviewed. **Relevance:** Admin-triggered notifications (e.g., moderation decisions) must be logged and reviewed. Supports accountability. **Integration Tips:** Restrict access to logs, enable integrity protection, and schedule reviews of admin activity related to notifications. **Verification Method:** Access control check on log store and evidence of periodic reviews. **Priority:** Low #### 6.2.12. REQ-12: Administrator and moderator dashboard for content, user and role management ##### OWASP ASVS Controls **V4.1.3** **Requirement:** Verify that administrative interfaces are protected with strong authentication and enforced least privilege. **Relevance:** Admin and moderator dashboards require stronger protections due to high impact. Enforces least privilege on powerful actions. **Integration Tips:** Require MFA for admin accounts, isolate admin UI, and implement fine-grained roles for moderation vs admin tasks. **Verification Method:** Check admin auth configuration, MFA enforcement, and role matrix. **Level:** L2 | **Priority:** Critical ##### NIST SP 800-53 Controls **AC-5** **Requirement:** Separate duties of individuals to reduce the risk of malevolent activity without collusion. **Relevance:** Separates moderating content from managing roles/users to reduce risk. Prevents concentration of power. **Integration Tips:** Create distinct roles and workflows requiring dual control for sensitive changes. Log approvals and changes. **Verification Method:** Review role definitions and evidence of dual-control workflows. **Priority:** High **AU-12** **Requirement:** Provide audit record generation capability for defined auditable events within the system. **Relevance:** Admin dashboards must generate detailed audit records for actions on users and roles. Supports traceability. **Integration Tips:** Instrument all admin actions to emit auditable events and centralize logs. Protect logs from tampering. **Verification Method:** Audit event catalog review and sampling of admin action logs. **Priority:** High ##### ISO 27001:2022 Controls **A.9.2.6** **Requirement:** The access rights of all employees and external party users to information and information processing facilities shall be removed upon termination or adjusted upon change. **Relevance:** Ensures timely adjustment of admin/moderator access when roles change. Reduces insider risk. **Integration Tips:** Automate deprovisioning and role adjustments through IAM; tie to HR events. Periodic access reviews. **Verification Method:** Access recertification records and deprovisioning audit trails. **Priority:** Medium #### 6.2.13. REQ-13: Reporting and abuse-flagging system with dispute handling ##### OWASP ASVS Controls **V7.2.1** **Requirement:** Verify that logs are protected from unauthorized access, tampering, and deletion. **Relevance:** Abuse reports may be evidence; logs must be protected to maintain integrity for dispute handling. **Integration Tips:** Use append-only log storage and restrict administrative access. Enable integrity checks and alerts on modifications. **Verification Method:** Configuration review of log storage and integrity verification mechanisms. **Level:** L1 | **Priority:** Medium ##### NIST SP 800-53 Controls **IR-4** **Requirement:** Implement an incident handling capability for incidents that includes preparation, detection and analysis, containment, eradication, and recovery. **Relevance:** Abuse reports trigger incident handling processes, including analysis and resolution. Establishes lifecycle for disputes. **Integration Tips:** Define triage SLAs and playbooks for abuse categories; integrate ticketing with evidence preservation. **Verification Method:** Review incident response playbooks and recent abuse case records. **Priority:** High **CM-9** **Requirement:** Develop, document, and implement a configuration management plan for the system that addresses roles, responsibilities, and configuration control. **Relevance:** Supports controlled changes to abuse handling workflows and tools, minimizing errors during disputes. **Integration Tips:** Document roles and change approval for moderation/abuse tooling configuration. Track changes in version control. **Verification Method:** Review CM plan and change logs for abuse tooling. **Priority:** Low ##### ISO 27001:2022 Controls **A.16.1.5** **Requirement:** Information security incidents shall be responded to in accordance with the documented procedures. **Relevance:** Requires documented procedures for reacting to abuse/disputes. Ensures consistency and compliance. **Integration Tips:** Create procedures covering intake, investigation, user communication, and closure. Train staff and log actions. **Verification Method:** Procedure review and training records; audit of closed dispute tickets. **Priority:** High #### 6.2.14. REQ-14: Automated expiry handling and lifecycle enforcement for adverts ##### OWASP ASVS Controls **V9.4.2** **Requirement:** Verify that data retention and disposal for sensitive data is defined, aligned to business need and regulatory requirements. **Relevance:** Adverts should expire and be purged/archived per policy to reduce data exposure. Defines lifecycle enforcement. **Integration Tips:** Implement retention policies and scheduled jobs to archive or delete expired adverts; document exceptions. **Verification Method:** Review retention schedules and job configurations; sample expired records. **Level:** L2 | **Priority:** High **V2.7.1** **Requirement:** Verify that sessions have a defined idle timeout and absolute timeout aligned to the business risk. **Relevance:** Though session-focused, timeouts exemplify lifecycle enforcement of time-bound entities. Supports consistent expiry handling patterns. **Integration Tips:** Adopt similar scheduled expiration patterns for adverts as sessions: absolute end-of-life and grace periods. **Verification Method:** Check timeout settings and compare with advert expiry jobs for consistency. **Level:** L1 | **Priority:** Low ##### NIST SP 800-53 Controls **AU-11** **Requirement:** Retain audit records for an organization-defined time period to provide support for after-the-fact investigations. **Relevance:** While adverts expire, related audit records must be retained appropriately for investigations. Balances lifecycle with audit needs. **Integration Tips:** Separate advert content lifecycle from audit log retention; configure different retention windows and storage classes. **Verification Method:** Policy review and storage configuration for differing retention periods. **Priority:** Medium #### 6.2.15. REQ-15: Paid-tier features: priority listing, branding, analytics, subscription and one-off payments ##### OWASP ASVS Controls **V4.2.3** **Requirement:** Verify that the application enforces authorization checks for each function, especially paid or premium features. **Relevance:** Critical to ensure only paying users access premium features like priority listings and branding. **Integration Tips:** Gate premium endpoints on subscription status claims and re-check on each call. Include checks in background jobs as well. **Verification Method:** Attempt to access premium features with non-paid accounts; review authorization middleware. **Level:** L2 | **Priority:** Critical **V10.4.3** **Requirement:** Verify that business logic enforces integrity of transactions and prevents abuse such as privilege escalation or bypass of payment checks. **Relevance:** Prevents users from bypassing payment or escalating privileges to gain premium features. **Integration Tips:** Implement server-side verification of payment status with PSP, and integrity checks on feature flags. Log anomalies. **Verification Method:** Business logic tests simulating tampering with client-side flags and stale receipts. **Level:** L2 | **Priority:** High ##### NIST SP 800-53 Controls **AU-2** **Requirement:** Define auditable events and ensure that the information system generates audit records for those events. **Relevance:** Paid feature access and changes to subscription states must be auditable for dispute resolution and fraud detection. **Integration Tips:** Log subscription activations, cancellations, and premium feature access with user and transaction IDs. **Verification Method:** Audit event catalog review and sampling of payment-related logs. **Priority:** Medium ##### ISO 27001:2022 Controls **A.12.1.1** **Requirement:** Operating procedures shall be documented and made available to all users who need them. **Relevance:** Defines procedures for subscription management, refunds, and disputes to reduce errors and fraud. **Integration Tips:** Document SOPs for handling subscription changes and one-off payments; train support staff. **Verification Method:** SOP review and training records. **Priority:** Low #### 6.2.16. REQ-16: Secure payment gateway integration and payment record management ##### OWASP ASVS Controls **V9.2.2** **Requirement:** Verify that connections to external payment service providers use strong TLS and validate certificates. **Relevance:** Protects payment data in transit to PSPs, preventing MITM attacks. Essential for secure gateway integration. **Integration Tips:** Enforce TLS 1.2+ with certificate validation and hostname verification; consider certificate pinning for PSP endpoints. **Verification Method:** TLS scan and connection tests to PSP endpoints; review client configuration. **Level:** L1 | **Priority:** Critical **V9.3.2** **Requirement:** Verify that payment-related data stored is minimized and protected using strong encryption and key management. **Relevance:** Minimizes and protects stored payment records, reducing PCI scope and breach impact. **Integration Tips:** Avoid storing PAN; store only tokens and necessary metadata encrypted with strong KMS-managed keys. Restrict access via RBAC. **Verification Method:** Data inventory and storage encryption configuration review; access audit. **Level:** L2 | **Priority:** High ##### NIST SP 800-53 Controls **SA-9** **Requirement:** Require that providers of external information system services comply with organizational information security requirements. **Relevance:** Mandates that the PSP meets security requirements, aligning integration with organizational policies. **Integration Tips:** Assess PSP security posture and include compliance reporting requirements. Monitor PSP changes impacting security. **Verification Method:** Third-party risk assessment records and periodic reassessment reports. **Priority:** Medium ##### ISO 27001:2022 Controls **A.15.1.1** **Requirement:** Information security requirements for mitigating the risks associated with supplier’s access to the organization’s assets shall be agreed with the supplier and documented. **Relevance:** Covers contractual and security requirements with payment gateway providers. Ensures third-party compliance. **Integration Tips:** Define SLAs, security clauses, breach notification, and data protection requirements with the PSP. Review SOC/PCI reports. **Verification Method:** Supplier agreement review and third-party assurance evidence. **Priority:** Medium #### 6.2.17. REQ-17: Logging, audit trails, and analytics for moderation, payments and admin actions ##### OWASP ASVS Controls **V7.1.3** **Requirement:** Verify that logs are generated for administrative actions, access control events, and security-relevant events. **Relevance:** Directly addresses logging of admin actions, payments, and moderation as security-relevant events. **Integration Tips:** Adopt structured logging with unique IDs; centralize logs in a SIEM; ensure clocks are synchronized. **Verification Method:** Log sampling and SIEM ingestion verification for all target event types. **Level:** L1 | **Priority:** Critical ##### NIST SP 800-53 Controls **AU-8** **Requirement:** Use internal system clocks to generate time stamps for audit records with sufficient granularity to meet system requirements. **Relevance:** Accurate timestamps are vital for correlating events across moderation and payment systems. **Integration Tips:** Enable NTP across services and include timezone and precision in logs. Use consistent time formats (e.g., RFC3339). **Verification Method:** Check NTP configuration and compare timestamps across services. **Priority:** High **AU-9** **Requirement:** Protect audit information and audit tools from unauthorized access, modification, and deletion. **Relevance:** Ensures audit data and tooling cannot be tampered with by admins or attackers. Critical for trustworthiness. **Integration Tips:** Separate duties for log management; restrict and monitor access to SIEM and log pipelines. **Verification Method:** Access review for log tools and attempted unauthorized modification test. **Priority:** High ##### ISO 27001:2022 Controls **A.12.4.2** **Requirement:** Logging facilities and log information shall be protected against tampering and unauthorized access. **Relevance:** Protects audit trails integrity for high-stakes areas like payments and admin actions. **Integration Tips:** Use append-only storage, role-based access to logs, and cryptographic integrity verification. **Verification Method:** Inspect log storage controls and integrity check outcomes. **Priority:** High #### 6.2.18. REQ-18: Privacy and data protection controls (GDPR compliance, consent management, data subject requests) ##### OWASP ASVS Controls **V1.4.4** **Requirement:** Verify that consent is obtained, recorded, and can be withdrawn for personal data processing. **Relevance:** Covers consent management lifecycle required by GDPR, including withdrawal. **Integration Tips:** Implement a consent store with versioning and timestamps; enforce consent checks in data processing flows. **Verification Method:** Examine consent records and test withdrawal propagation to processing systems. **Level:** L2 | **Priority:** High ##### NIST SP 800-53 Controls **AR-8** **Requirement:** Provide an accounting of disclosures of personally identifiable information to individuals upon request. **Relevance:** Supports GDPR data subject rights by tracking disclosures for subject access requests. **Integration Tips:** Maintain disclosure logs linked to data subjects and expose them via DSAR workflows. **Verification Method:** Review disclosure log schema and perform a test DSAR. **Priority:** Medium ##### ISO 27001:2022 Controls **A.18.1.4** **Requirement:** Privacy and protection of personally identifiable information shall be ensured as required in relevant legislation and regulation. **Relevance:** Directly mandates GDPR-aligned protections for PII, covering lawful processing and safeguards. **Integration Tips:** Map processing activities, implement DPIAs where applicable, and enforce access controls on PII. **Verification Method:** Review ROPA/DPIA documents and PII access controls. **Priority:** Critical **A.18.1.1** **Requirement:** All relevant legislative statutory, regulatory and contractual requirements shall be explicitly identified and documented for each information system. **Relevance:** Requires identifying GDPR and other legal obligations, forming the basis of privacy control implementation. **Integration Tips:** Maintain a compliance register mapping requirements to controls and evidence. Review updates regularly. **Verification Method:** Audit the compliance register and control mappings. **Priority:** Medium #### 6.2.19. REQ-19: Security controls: encryption in transit and at rest, RBAC, MFA option, rate limiting and anti-abuse protections ##### OWASP ASVS Controls **V9.1.2** **Requirement:** Verify that all sensitive data is identified and classified, and appropriate protections are applied. **Relevance:** Data classification is prerequisite to applying correct encryption at rest/in transit and access controls. **Integration Tips:** Create a data classification inventory and map protections (TLS, encryption at rest, access policies) per class. **Verification Method:** Review data inventory and control mappings to classification levels. **Level:** L1 | **Priority:** Critical **V2.7.5** **Requirement:** Verify that session management and authentication support multi-factor authentication where appropriate. **Relevance:** Satisfies MFA option requirement to harden authentication. Reduces account takeover risk. **Integration Tips:** Offer TOTP/WebAuthn MFA and provide recovery mechanisms; enforce MFA for high-privilege roles. **Verification Method:** Test MFA enrollment and enforcement; review auth configuration. **Level:** L2 | **Priority:** High ##### NIST SP 800-53 Controls **SC-12** **Requirement:** Establish and manage cryptographic keys for required cryptography employed within the information system. **Relevance:** Proper key management underpins encryption at rest and in transit. Prevents compromise of protected data. **Integration Tips:** Use managed KMS/HSM for key lifecycle, rotation, and access controls; enforce separation of duties for key admins. **Verification Method:** Key management policy review and evidence of key rotation/audit logs. **Priority:** High **SI-10** **Requirement:** Check the validity of information inputs. **Relevance:** Input validation is fundamental to anti-abuse; combined with rate limiting prevents injection and resource abuse. **Integration Tips:** Apply centralized validation schemas and integrate with rate-limiting middleware at gateway level. **Verification Method:** Code review of validation and gateway configs; fuzz testing of endpoints. **Priority:** Medium #### 6.2.20. REQ-20: Accessibility and mobile responsiveness (WCAG conformance target) ##### OWASP ASVS Controls **V1.3.1** **Requirement:** Verify that security is addressed in user experience and design, including error messages and user guidance that do not leak sensitive information. **Relevance:** While WCAG is accessibility-focused, secure UX ensures accessible error handling without leaking sensitive data. **Integration Tips:** Design accessible error states and guidance that are clear yet do not expose internals. Include security considerations in UX reviews. **Verification Method:** UX review of error messages and accessibility testing. **Level:** L1 | **Priority:** Low **V7.3.1** **Requirement:** Verify that error messages are handled in a user-friendly manner without revealing sensitive information. **Relevance:** Accessible applications need clear errors, but they must not expose sensitive details. This balances both goals. **Integration Tips:** Return generic messages to users and detailed errors only in logs. Ensure messages meet accessibility guidelines (e.g., ARIA). **Verification Method:** UI testing for error content and accessibility audits. **Level:** L1 | **Priority:** Low ##### NIST SP 800-53 Controls **RA-5** **Requirement:** Scan for vulnerabilities in the information system and hosted applications and address identified vulnerabilities. **Relevance:** Responsive frontends may introduce security flaws; ongoing scanning and remediation sustains a secure, accessible experience. **Integration Tips:** Run regular dynamic scans against mobile and responsive views and triage findings promptly. **Verification Method:** Scan reports and remediation tracking. **Priority:** Low ##### ISO 27001:2022 Controls **A.14.2.1** **Requirement:** Rules for the development of software and systems shall be established and applied to developments within the organization. **Relevance:** Secure development policies should include accessibility considerations to reduce security issues in responsive UIs. **Integration Tips:** Incorporate accessibility checks into SDLC and code review policies alongside security checks. **Verification Method:** Policy review and pipeline checks for accessibility/security gates. **Priority:** Low ### 6.3. Cross-Functional Security Controls The following controls apply globally across all system components: **Transport Layer Security** *Description:* Encrypt all data in transit using strong TLS and validate certificates. *Applies to:* User registration and login with role assignment and secure authentication, Secure in-app messaging between users with optional verified contact reveal, Secure payment gateway integration and payment record management, Notifications system for adverts, messages and moderation status, Interactive map with clustering and approximate location display *Implementation Guidance:* Enforce TLS 1.2+ with modern ciphers, HSTS, and certificate validation/pinning where appropriate. **Centralized Authorization (RBAC/ABAC)** *Description:* Consistent server-side authorization for all protected resources and operations. *Applies to:* User registration and login with role assignment and secure authentication, Email domain verification and tier-based access controls (free vs paid advertisers), Advert creation, edit, delete lifecycle with support for multi-room properties, Administrator and moderator dashboard for content, user and role management, Paid-tier features: priority listing, branding, analytics, subscription and one-off payments *Implementation Guidance:* Use a policy engine or middleware to enforce per-request checks based on roles/attributes; deny by default. **Comprehensive Logging and Audit** *Description:* Generate, protect, and review logs for security-relevant events and administrative activities. *Applies to:* Automated and manual moderation workflow for adverts and content, Notifications system for adverts, messages and moderation status, Administrator and moderator dashboard for content, user and role management, Logging, audit trails, and analytics for moderation, payments and admin actions, Reporting and abuse-flagging system with dispute handling *Implementation Guidance:* Use structured logs with timestamps and correlation IDs; protect logs from tampering and perform regular reviews in a SIEM. **Input Validation and Output Encoding** *Description:* Validate all inputs and encode outputs to prevent injection and XSS. *Applies to:* Advert creation, edit, delete lifecycle with support for multi-room properties, Advanced filtering, saveable searches, and alerting (instant and daily digest), Interactive map with clustering and approximate location display, Notifications system for adverts, messages and moderation status *Implementation Guidance:* Adopt positive validation using schemas and perform contextual output encoding in templates and UI components. **Privacy by Design and Data Minimization** *Description:* Minimize collection and exposure of personal and location data and provide user controls. *Applies to:* User profile management with verifiable contact display options, Geo-centric search and filtered discovery with map visualisation (approximate locations), Interactive map with clustering and approximate location display, Privacy and data protection controls (GDPR compliance, consent management, data subject requests) *Implementation Guidance:* Classify data, limit retention, mask or approximate sensitive fields, and implement consent and data subject rights workflows. ### 6.4. Requirements Traceability Overview This section demonstrates complete traceability from high-level requirements through threats to security controls and verification methods. **Coverage Summary:** Traceability matrix contains 20 requirements. 20 requirements (100.0%) linked to threats. 17 requirements (85.0%) mapped to security controls (OWASP ASVS, NIST SP 800-53, ISO 27001). Coverage: Partial. #### Sample Traceability Mappings The following table shows traceability for high-priority requirements: | Req ID | Requirement | Threats | Security Controls | Standards | Priority | Verification | |--------|-------------|---------|-------------------|-----------|----------|-------------| | REQ-001 | User registration and secure login with ... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Review access provisioning SOPs, sampling of access requests, and RBAC review records. | | REQ-002 | Email domain verification for free-tier ... | 7 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Review service access configurations and test unauthorized access attempts. | | REQ-003 | User profile management capturing displa... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Access tests for different roles and review of API authorization rules. | | REQ-004 | Advert lifecycle management: create, sav... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Policy review and data-layer query inspection for authorization predicates. | | REQ-007 | Moderator and Administrator dashboard to... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Audit event catalog review and sampling of admin action logs. | | REQ-011 | Favourites/bookmarks management: allow u... | 8 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Policy review and functional testing of access restrictions. | | REQ-012 | Secure in-app messaging system that medi... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Review cipher suites and test integrity verification on message transport. | | REQ-015 | Paid-tier features: priority listing / b... | 6 threats | 4 controls | ISO27001, NIST, OWASP | Critical | SOP review and training records. | | REQ-016 | Secure payment processing via a PCI-DSS-... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | TLS scan and connection tests to PSP endpoints; review client configuration. | | REQ-017 | GDPR-compliant data handling: obtain exp... | 10 threats | 4 controls | ISO27001, NIST, OWASP | Critical | Examine consent records and test withdrawal propagation to processing systems. | *Showing 10 of 20 requirements. See Appendix D for complete traceability matrix.* #### Traceability Statistics - **Total Requirements Tracked:** 20 - **Requirements Linked to Threats:** 20 (100.0%) - **Requirements Mapped to Controls:** 17 (85.0%) - **Average Controls per Requirement:** 3.4 - **Control Distribution by Standard:** - OWASP ASVS: 30 controls - NIST SP 800-53: 21 controls - ISO 27001: 17 controls - **Verification Coverage:** 100% (all requirements have verification methods) --- ## 7. AI/ML Security Requirements This section addresses security requirements specific to artificial intelligence and machine learning components within the system. AI/ML systems introduce unique security challenges including prompt injection attacks, data poisoning, model theft, adversarial inputs, and bias vulnerabilities. This analysis identifies AI/ML components, assesses their security risks, and prescribes specialized controls to protect both the AI systems themselves and the data they process. ### 7.1. AI/ML Components Detected This section identifies all AI/ML components within the system that require specialized security controls. 1. **Automated Moderation System**: AI-powered system for detecting spam and malicious content in adverts before publication. 2. **In-app Messaging System**: Potential use of natural language processing to enhance user communication and support. 3. **Search and Filtering Mechanism**: AI algorithms to improve geo-centric search results and personalized suggestions based on user behavior. ### 7.2. AI/ML Threat Model | Component | Identified Threats | |---------------------------------|------------------------------------------------| | Automated Moderation System | - Prompt injection<br>- Data leakage<br>- Adversarial inputs | | In-app Messaging System | - Prompt injection<br>- Data leakage<br>- Adversarial inputs | | Search and Filtering Mechanism | - Adversarial inputs<br>- Data leakage<br>- Bias in recommendations | ### 7.3. AI/ML Security Controls #### Automated Moderation System **Prompt Injection Prevention**: Implement context-aware filtering to ensure inputs do not exploit the system. **Data Leakage Prevention**: Regularly audit training data to ensure no sensitive PII is present. **Output Filtering and Sanitization**: Strip sensitive or harmful information from outputs before display. #### In-app Messaging System **Input Validation for AI Inputs**: Validate and sanitize all messages to prevent harmful injections. **Model Access Controls**: Limit access to the NLP models used for messaging to authorized personnel only. **Monitoring for Adversarial Inputs**: Use anomaly detection algorithms to flag unusual patterns in messaging. #### Search and Filtering Mechanism **Rate Limiting and Abuse Prevention**: Implement rate limits on search queries to prevent abuse of system resources. **Monitoring for Adversarial Inputs**: Regularly update the filtering algorithms to identify and mitigate adversarial manipulation of search results. **Bias and Fairness Considerations**: Continuously evaluate and adjust the model to avoid biased recommendations based on user data. ### 7.4. Integration with Existing Security Controls AI security controls will integrate with existing practices such as encryption, role-based access control (RBAC), and GDPR compliance measures. For instance, outputs from the AI components will be encrypted to protect sensitive data, and user roles will dictate access levels to AI functionalities, ensuring that only authorized users can modify or interact with these systems. ### 7.5. AI/ML Monitoring Requirements | Monitoring Area | Description | |---------------------------------|-------------------------------------------------| | Automated Moderation System | Continuous monitoring for false positives and negatives in spam detection. | | In-app Messaging System | Logging and analysis of message patterns to detect potential abuse or manipulation. | | Search and Filtering Mechanism | Ongoing evaluation of search results for fairness and accuracy, along with user feedback collection. | --- ## 8. Compliance Requirements This section identifies regulatory and legal compliance obligations applicable to the system based on data types, geographic scope, industry sector, and business operations. Compliance requirements drive specific security controls, data handling procedures, audit capabilities, and privacy protections. Non-compliance can result in significant legal penalties, reputational damage, and business disruption. This analysis maps applicable regulations to specific security requirements and operational procedures. ### 8.1. Applicable Regulations The identification of applicable regulations is based on the types of data processed, the geographic scope of operations, the nature of the services provided, and the industry sector involved. The platform handles personal data from users, which includes their contact information, preferences, and communication logs. Additionally, it incorporates payment processing features that are subject to financial regulations. The GDPR is particularly relevant due to the handling of personal data from EU residents, while CCPA applies to California residents. The table below outlines the specific regulations relevant to the platform's operations. | Regulation | Applicability Reason | |------------|----------------------| | GDPR | The system processes personal data of EU residents, requiring compliance with data protection regulations. | | CCPA | The platform collects personal information from California residents, necessitating compliance with state privacy laws. | | PCI-DSS | The integration of a secure payment gateway for subscription and one-off payments involves handling payment card data. | | COPPA | The platform must ensure compliance if users include minors, requiring additional protections for children's data. | | Data Residency Laws | The platform may need to comply with data residency requirements based on the geographic locations of its users. | ### 8.2. Compliance Controls by Regulation #### GDPR - Implement clear consent mechanisms for data processing. - Ensure data minimization principles are followed (only collect necessary data). - Enable data subject rights management (access, correction, deletion). - Use encryption for data at rest and in transit. #### CCPA - Provide clear privacy notices regarding data collection and use. - Allow users to opt out of the sale of their personal information. - Implement mechanisms for users to request disclosure of their data. - Ensure appropriate training for staff handling personal data. #### PCI-DSS - Encrypt cardholder data during transmission. - Maintain a secure network with firewalls and security protocols. - Restrict access to cardholder data on a need-to-know basis. - Regularly monitor and test networks for vulnerabilities. #### COPPA - Obtain verifiable parental consent for users under 13. - Provide clear information about data collection practices for minors. - Implement age verification mechanisms during account creation. #### Data Residency Laws - Identify data storage locations to ensure compliance with local regulations. - Implement data transfer restrictions based on jurisdictional requirements. ### 8.3. Data Subject Rights | Right | Description | |---------------------------|-------------------------------------------------------| | Right to Access | Users can request access to their personal data. | | Right to Rectification | Users can request corrections to inaccurate data. | | Right to Erasure | Users can request deletion of their personal data. | | Right to Data Portability | Users can request to receive their data in a structured format. | | Right to Restrict Processing | Users can request to limit the processing of their data. | ### 8.4. Privacy Requirements **Consent:** Users must provide explicit consent for data collection, processing, and sharing. **Privacy Notice:** Clear and accessible privacy notices must inform users about data handling practices. **Data Protection Impact Assessment:** Conduct assessments to evaluate risks associated with data processing activities. ### 8.5. Audit and Monitoring Requirements **Logging:** Maintain detailed logs of data access and modifications by users and administrators. **Monitoring:** Regular audits to ensure compliance with security and privacy controls. **Incident Response Plan:** Develop and implement a plan for responding to data breaches and security incidents. ### 8.6. Data Handling Rules **Retention:** Data should only be retained for as long as necessary for the purposes for which it was collected. **Deletion:** Implement processes for securely deleting data once it is no longer needed. **Access Controls:** Limit access to personal data to authorized individuals only. ### 8.7. Compliance Risk Assessment The compliance risk assessment identifies potential risks associated with failing to adhere to applicable regulations. It is essential to recognize these risks to implement effective control measures and protect user data. **Key Compliance Risks:** - Non-compliance with GDPR and CCPA, leading to potential fines and legal action. - Inadequate protection of payment card data under PCI-DSS, resulting in financial loss and reputational damage. - Failure to obtain necessary consent for the collection of children's data under COPPA, leading to legal repercussions. - Data breaches due to insufficient security measures, impacting user trust and compliance standing. --- ## 9. Security Architecture Recommendations This section provides comprehensive security architecture guidance that integrates security controls into the system's technical design. Security architecture defines how security principles, controls, and patterns are applied across system components to create a cohesive, defense-in-depth security posture. The recommendations address architectural principles, component-level controls, data protection strategies, and third-party integration security to ensure security is built into the system design. ### 9.1. Architectural Security Principles Architectural security principles provide the foundational philosophy guiding all security design decisions. These principles ensure a consistent security posture across system components and guide the selection and implementation of controls so that the geo-centric student household vacancy platform remains resilient, privacy-preserving and compliant while usable and scalable. - **Zero Trust Architecture principles**: Never trust, always verify — every request (user, service, device) must be authenticated and authorized regardless of network location. This reduces implicit trust of internal networks and prevents lateral movement after compromise. - **Defense in Depth**: Apply multiple, independent layers of controls (network, host, application, data, identity) so that the failure of one control does not result in full compromise. Layering supports resilience and progressive detection/containment. - **Principle of Least Privilege**: Grant users, services and processes only the minimum permissions required to perform tasks. Minimizing privileges limits blast radius and eases auditability. - **Secure by Default / Secure by Design**: Build security into architecture and defaults (secure configurations, hardened images, secure libraries) so safe behavior is the natural behavior for users and operators. - **Separation of Duties**: Divide critical responsibilities (e.g., moderation vs role management, payments vs refunds) to reduce insider risk and require collusion for harmful actions. - **Fail Secure (Fail Safe)**: Systems should default to a secure state on failure (deny access on policy or system failures, freeze critical actions when validation fails). - **Complete Mediation**: Authorize every access to a protected resource (no implicit caching of authorization decisions without re-validation when state changes). - **Defense in Depth for Privacy (Privacy-by-Design)**: Minimize collection and retention of PII and location data; employ pseudonymization and data minimization patterns at each layer. - **Secure Defaults for External Integrations**: Treat every third-party dependency as untrusted; enforce strong contractual security requirements and protect secrets and traffic to/from them. - **Observable and Auditable**: Instrument all security-relevant events (auth, admin, moderation, payments) with structured logs, immutable audit trails and SIEM monitoring for detection and forensics. --- ### 9.2. Component-Level Security Controls #### Frontend User Interface **Required Controls:** - Enforce Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, Referrer Policy, and secure SameSite cookies. - Protect against XSS, CSRF and clickjacking with input sanitization and CSRF tokens. - Enforce client-side validation only as UX convenience; rely on server-side validation for enforcement. - Avoid embedding secrets/API keys; use short-lived tokens acquired from backend. - Serve assets via CDN with WAF protections and TLS 1.3. - Protect saved searches/favourites UI with strict per-user authorization checks. **Recommended Patterns:** - SPA served from CDN + WAF with edge security rules. - OAuth2/OIDC flows for session management (authorization code + PKCE for public clients). - Strict separation of UI and API surface; API calls go to API Gateway. - Use safe templating libraries and sanitize map/pop-up content. - Implement offline-safe data stores (IndexedDB) with careful encryption of anything sensitive. #### Edge Layer (CDN / WAF / API Gateway) **Required Controls:** - Global TLS termination with TLS 1.3, HSTS and strong cipher suites. - WAF rules for OWASP Top 10 protections, bot management and IP reputation blocking. - API Gateway enforcing authentication, rate limits, quotas, and per-API authorization (tier checks). - Request/response validation, schema enforcement and size limits at the gateway. - IP reputation blocking and geo-restriction support where relevant. **Recommended Patterns:** - API Gateway with OAuth2 introspection/JWT validation and per-route policies. - Edge caching for public assets; dynamic content routed to backend. - Rate limiting (per-API, per-user, per-IP) and dynamic throttling. - Use edge WAF + CDN for DDoS mitigation and caching; integrate WAF alerts into SIEM. #### Application Services **Required Controls:** - Centralized authentication and authorization (RBAC/ABAC) enforced per-request. - Mutual TLS or service-to-service authentication (mTLS or strong mTLS alternatives) inside the platform. - Input validation and output encoding at service boundaries. - Secure secrets handling (secrets manager / vault) and parameterized DB queries to prevent injection. - Service-level logging with correlation IDs; redact PII in logs. - Circuit-breakers, throttling, idempotency for message handling. - Hardened container or server images with vulnerability scanning. **Recommended Patterns:** - API Gateway in front of microservices; microservices behind a service mesh (mTLS, observability). - Policy engine for attribute-based access controls (e.g., OPA/Rego). - Messaging via durable queues (SQS/Kafka) with encryption-at-rest and access control. - Use multi-tenant aware services with scoped keys for user records and adverts. #### Data Storage **Required Controls:** - Encrypt all data at rest using strong algorithms (TDE for RDBMS + column-level encryption for PII). - Row/column-level access controls for PII and adverts metadata. - Database access only from application subnets and via least-privileged DB roles. - Secure object storage for media with signed short-lived URLs and content scanning (malware, PII detection). - Harden backups and snapshots (encrypted, stored in separate account/region, immutable storage where required). **Recommended Patterns:** - Encrypted RDBMS with Transparent Data Encryption (TDE) + column encryption for PII. - Use search index (Elasticsearch/OpenSearch) in private VPC, pre-processed and stripped of exact coordinates/PII. - Object storage (S3/GCS/Azure Blob) with per-object KMS encryption and lifecycle policies. - Use Data Access layer that enforces owner scoping and ABAC predicates. #### External Services **Required Controls:** - Store API credentials in secrets manager and rotate regularly. - Use minimal privilege scopes for service accounts/APIs. - Verify TLS certificates, enable certificate pinning where possible and validate webhook signatures. **Recommended Patterns:** - Controlled egress via NAT gateways and allowlists; centralized outbound proxy for HTTP(s) with logging. - Use signed webhooks with HMAC verification and replay protections. - Integrate third-party SDKs with explicit review and limit scope in CSP. #### Admin & Moderation **Required Controls:** - Admin UI protected by SSO with mandatory MFA for admin/moderator roles. - Role separation: distinct moderator and administrator roles, with dual-control for destructive actions. - JIT (Just-in-Time) and step-up authentication for sensitive actions. - Full audit logging for all admin and moderation actions, immutable storage and SIEM alerting. **Recommended Patterns:** - Isolated admin network / bastion hosts and conditional access policies (IP allowlists, client certs). - Use privileged access management (PAM) for elevated actions. - Workflow-based moderation queue with evidence preservation and versioned actions. #### Notifications & Messaging **Required Controls:** - TLS 1.3 for API/Websocket connections and delivery channels where applicable. - Messages encrypted at rest; retention and redaction rules applied for PII. - Content scanning and sanitization for message text to remove malware and PII before delivery. - Rate limiting and anti-automation controls for outgoing notifications. **Recommended Patterns:** - Mediated messaging model (no direct user contact unless verified + step-up). - Use queueing system (SQS/Kafka) and worker pools with backpressure handling. - Template engines with contextual encoding for email and push (no raw HTML from users). #### Payments & Billing **Required Controls:** - No storage of PAN; use PSP tokenization and maintain PCI-compliant integration patterns. - Enforce TLS, certificate validation and strong authentication for payment operations. - Logging of payment events with strict access control and separation of logs vs transaction payloads. **Recommended Patterns:** - Redirect / hosted payment page or tokenization via client-side PSP SDKs to minimize PCI scope. - Server-side verification of payment status via PSP webhooks with signed payloads. - Payment gateway integration through isolated environments and role-limited service accounts. --- ### 9.3. Data Protection Strategy **Data Classification:** Public, Internal, Confidential, Restricted - Public: Aggregated non-identifying adverts metadata, neighbourhood heatmaps (no PII or exact coords). - Internal: System telemetry, anonymized analytics, non-sensitive application metadata. - Confidential: User profile PII (name, email, phone when verified), messaging contents, billing metadata (excluding PAN tokens), saved searches/favourites. - Restricted: Exact addresses (if stored by consent), payment PAN (should never be stored), verification documents (IDs), and admin audit logs that could be used for abuse or identity theft. **Encryption Requirements:** - Data in transit: TLS 1.3 mandatory for all external and internal HTTP(s) endpoints; HSTS for web. Use mutual TLS for service-to-service where practical. - Data at rest (databases / object storage): - Use AES-256-GCM for envelope/data key encryption (AES-256 with GCM for authenticated encryption). - Use KMS/HSM-backed Customer Master Keys (CMKs) with envelope encryption for data keys. - Column-level encryption for high-risk fields (e.g., user contact details, identity docs) with AEAD. - Passwords: - Store using Argon2id (recommended parameters: memory ~64MB-256MB, iterations >=3, parallelism 1-4 depending on load) or bcrypt with strong parameters if Argon2 not available. - Asymmetric crypto: - Use ECDSA or ECDH with curve P-256 or P-384 for signatures and key exchange; RSA-3072+ if RSA used. - Key lifetimes & rotation: - Data keys rotated every 90 days; CMKs rotated yearly or per policy. - Enable automatic KMS key rotation and maintain key access logs. - Logging & backups: - Ensure audit logs are encrypted with separate keys and stored in append-only or WORM storage. **Retention Policies:** - Adverts (active): retain until expiry + configurable grace period (default 90 days) then archive for investigation for a minimal period (e.g., 12 months) before secure deletion unless legal reasons require longer retention. - Expired/Deleted adverts: soft-delete immediately; physical deletion or shredding from primary store after retention period. Keep audit records for a longer period (e.g., 2–7 years depending on legal/compliance). - Messaging: retain for business needs with a default of 180 days for in-app messages, configurable by admin policy; redact/delete on DSAR or upon user deletion subject to moderation evidence preservation needs. - Payment metadata: keep transaction metadata for tax and invoicing per local law (typically 7 years for many jurisdictions) but do not store PAN. Store PSP tokens and minimal metadata. - Logs & audit trails: security logs retained in SIEM per organizational policy (e.g., 1 year hot storage, 3–7 years cold archival) and protected from tampering. - Verification documents: retain only as long as necessary for verification, default 12 months, unless required to retain longer by law. **Handling Procedures:** - Access: - Enforce RBAC/ABAC for all data access; require least privilege for operators. - Admin access to PII requires MFA and justifications recorded; use break-glass with approvals. - Transmission: - All transmissions over TLS 1.3+; use signed authentication tokens (JWTs with short TTLs) and refresh patterns. - For third-party calls, use mTLS where available or strict TLS with certificate validation and allowlist endpoints. - Storage: - Use envelope encryption with KMS for objects and database fields. Apply separation of keys for different environments (prod/test). - Search index must not contain raw PII or exact coordinates; include pseudonymized IDs and approximate geohash. - Deletion: - Implement deterministic deletion workflows: soft-delete flag, then scheduled purge jobs. Ensure backups retention policies are aligned and that purges also remove data from backups per policy constraints. - Data Subject Requests (DSAR): - Maintain ROPA and consent store; implement automated DSAR exports and erasure workflows that cascade to search indexes, caches, third-parties where feasible and log all actions. - Pseudonymization & Approximation: - Store approximate location (coarse geohash / grid cell) for all public exposures. Exact coordinates, if ever needed, must be separately encrypted and access-controlled and only accessible with explicit consent and justification. - Monitoring & Alerting: - Monitor access patterns to PII and generate alerts for anomalous access (unusual volumes, admin access outside business hours, bulk exports). - Test Data: - Prohibit use of live PII in non-prod. Provide synthetic or anonymized datasets for development/testing. --- ### 9.4. Third-Party Integration Security **Mapbox / Google Maps (Maps API)** *Security Requirements:* - Use API keys stored in a secrets manager, not hard-coded. - Enforce usage restrictions (HTTP referrer restrictions, domain allowlists). - Use TLS for all API calls. - Validate and monitor requests/quotas. *Risk Assessment:* High — map APIs are needed for geo visualisation; leak of exact coordinates or misuse of keys can reveal sensitive location metadata or run up costs. *Recommended Controls:* - Enable domain/referrer and IP restrictions on API keys. - Route third-party map calls through a controlled backend or egress proxy to avoid exposing keys to clients (or use short-lived tokens). - Limit map responses to coarse location; avoid storing raw tile metadata containing precise coordinates. - Monitor API usage, set quotas and alert on anomalies. **SendGrid / Mailgun or similar (Email Service Provider)** *Security Requirements:* - Store API keys in secrets manager with rotation. - Use TLS for SMTP/API. - Verify webhook signatures and use authenticated webhook endpoints. *Risk Assessment:* High — email channel can be abused for spam/phishing and leaks of PII. Misconfigured templates could allow injection/XSS. *Recommended Controls:* - Enforce templating that encodes user-provided content. - Apply rate limits for triggered emails and digest generation. - Monitor bounce/spam rates and reputation; implement DKIM, SPF, DMARC. - Validate webhooks via signature verification. **Firebase Cloud Messaging (FCM) / APNs (Push Providers)** *Security Requirements:* - Secure service credentials in vault; use per-environment credentials. - Use TLS for push provider connections. *Risk Assessment:* Medium — push notifications may leak content if not sanitized and can be abused to spam devices. *Recommended Controls:* - Throttle push notification sends and use user opt-in. - Avoid sending PII in push payloads; link into the app that requires authentication to view content. - Monitor push failures and detect unusual volumes. **Stripe / Adyen / Payment Gateway** *Security Requirements:* - PCI-DSS compliant integration; never store PAN. - Use tokenization for cards and TLS for all payment interactions. - Validate webhook signatures. *Risk Assessment:* Critical — financial data and billing operations; risk of fraud and regulatory exposure. *Recommended Controls:* - Use hosted payment pages or client-side tokenization (PSP SDK). - Restrict webhooks to endpoint allowlisted IPs and signed payloads. - Maintain contractually required assurances (PCI Attestation, SOC reports). - Perform reconciliation and fraud monitoring; log payment events in immutable audit logs. **CDN / WAF Provider (Cloudflare/Akamai/etc.)** *Security Requirements:* - Secure account with SSO + MFA for admin roles. - Use WAF rulesets, bot mitigation and DDoS protections. *Risk Assessment:* High — if compromised, it can affect content integrity and traffic flow. *Recommended Controls:* - Enable least-privileged admin roles and IP-restricted dashboard access. - Configure WAF rules tuned to application behavior and OWASP protections. - Use encryption (TLS), origin attestation (client certs to origin) and private network peering where possible. **Elasticsearch / OpenSearch (Search Index)** *Security Requirements:* - Restrict access to private VPC; require authentication and TLS. - Do not store raw PII or exact coordinates in the index. *Risk Assessment:* High — search clusters have had high-profile exposures; unprotected clusters leak sensitive data. *Recommended Controls:* - Network isolation (VPC), IP allowlists and IAM-based access controls. - Enable node-to-node TLS, authentication (e.g., native auth or proxy), encryption at rest. - Index only pseudonymized IDs and coarse geohashes; implement scrubber jobs to remove PII. **ML Moderation Tooling (Third-party / SaaS)** *Security Requirements:* - Clear data sharing contract and DPIA for sending content to third-party moderation services. - Prefer on-prem or private VPC deployment for sensitive content. *Risk Assessment:* Medium to High — content may include PII or sensitive images; sharing increases privacy risk and regulatory obligations. *Recommended Controls:* - Use privacy-preserving techniques (hashing, tokenization, on-device or on-prem inference where possible). - Log and monitor what content is sent, keep minimal context, and maintain consent/DSAR ability. - Contractual safeguards: data processing addendum, breach notification SLAs, deletion policies. **Identity Provider (SSO / Okta / Azure AD / Auth0)** *Security Requirements:* - Use OIDC/OAuth2 and enforce MFA for privileged roles. - Configure role/claim mappings and enforce SCIM for provisioning. *Risk Assessment:* High — identity provider compromise leads to broad access. *Recommended Controls:* - Enforce SSO with short session TTLs and conditional access (IP, device posture). - Monitor for suspicious sign-ins, enforce risk-based authentication and device postures. - Use just-in-time provisioning with automated de-provisioning on off-boarding. **Email/Push Webhooks and Notification Providers** *Security Requirements:* - Validate signatures for all incoming webhooks. - Restrict endpoints to provider IP ranges where available. *Risk Assessment:* Medium — unauthenticated webhooks enable spoofing and fraudulent state changes. *Recommended Controls:* - Use HMAC signatures, timestamp checks and replay protection. - Log webhook deliveries and failures and correlate with payment/notification events. **Analytics / Timeseries Tools (Datadog / New Relic)** *Security Requirements:* - Do not send raw PII to analytics providers. - Use secure API keys in secrets manager and limit dashboard access. *Risk Assessment:* Medium — leakage of PII into analytics can create compliance risk. *Recommended Controls:* - Scrub PII before sending; use pseudonymized identifiers. - Restrict analytics dashboards to authorized auditors and admins. --- Concluding notes (how elements work together): - Enforce identity-first control at every layer: edge validates token → gateway enforces RBAC/ABAC policies → services re-check ownership and apply data scoping. This implements Zero Trust and Complete Mediation. - Encryption and key management are foundational: KMS-backed envelope encryption protects PII/keys across storage, backups, and logs. - Privacy-by-design is enforced via approximate geolocation (coarse geohashes/grids) at ingestion and strict redaction of exact coordinates from search indexes, logs and map payloads. - Monitoring and response: central SIEM and alerting should aggregate auth, admin, moderation, payment and data-access events; automated playbooks (IR-4) drive triage for abuse and DSAR handling. - Third-party integrations are treated as untrusted endpoints with contractual, technical and operational mitigations (mTLS, webhooks signatures, tokenization, minimal scopes and rigorous logging). - Operational security: include deployment pipelines with SCA/DAST, periodic penetration testing, vulnerability management and privileged access management for administrators. This architecture and controls mapping meets the REQ-* mappings and ASVS L2 recommendations and will enable a secure, privacy-preserving student household vacancy platform when implemented under governed SDLC, continuous monitoring, and regular audit/review cycles. --- ## 10. Implementation Roadmap This section provides a prioritized, phased approach for implementing the security controls identified throughout this analysis. The roadmap organizes security measures into logical phases based on risk, dependencies, and resource availability, ensuring critical security gaps are addressed first while building a foundation for comprehensive security coverage. ### 10.1. Prioritization Framework Prioritization is essential for effectively implementing security controls within the constraints of time, resources, and business operations. By organizing security controls into phases, we can address the most critical risks first, ensure compliance with regulatory requirements, and lay the groundwork for future enhancements. The following criteria guide our prioritization: **Prioritization Criteria:** - **Risk Level**: Controls addressing critical and high-risk threats (identified through threat modeling) are prioritized first - **Compliance Deadlines**: Regulatory requirements and compliance deadlines influence immediate priority - **Technical Complexity**: Controls requiring foundational infrastructure are implemented early to enable subsequent controls - **Dependencies**: Controls that other security measures depend upon are prioritized accordingly - **Resource Availability**: Implementation considers the availability of skilled personnel, tools, and budget - **Business Impact**: Controls protecting business-critical functions and data receive higher priority These criteria work in concert to create a logical implementation sequence that balances security needs with practical constraints, ensuring that urgent security gaps are closed swiftly while setting the stage for comprehensive, long-term improvements. ### 10.2. Phased Implementation Plan #### Phase: IMMEDIATE **Timeline:** 0-1 months **Rationale:** This phase addresses the most critical vulnerabilities and compliance blockers that pose immediate risks to the platform's security and regulatory standing. **Controls to Implement:** - Implement robust password handling and secure authentication mechanisms - Establish role-based access control (RBAC) for all protected resources - Encrypt sensitive data in transit using TLS 1.2+ - Implement logging for security-relevant events - Ensure GDPR and PCI-DSS compliance by addressing blockers **Dependencies:** - None #### Phase: SHORT-TERM **Timeline:** 1-3 months **Rationale:** These controls build upon immediate security measures, focusing on improving access control adjustments and ensuring that logging and API security mitigate identified threats effectively. **Controls to Implement:** - Enhance user authentication through comprehensive multi-factor authentication - Deploy role-based access controls across the admin dashboard - Implement comprehensive logging and monitoring for all administrative actions - Strengthen API security with input validation and HTTPS protocols - Begin encryption for all sensitive data at rest **Dependencies:** - Completion of TLS Implementation - Completion of multi-factor authentication #### Phase: MEDIUM-TERM **Timeline:** 3-6 months **Rationale:** This phase focuses on implementing advanced security measures and enhancing data protection strategies that require more planning and integration. **Controls to Implement:** - Deploy advanced threat detection and response capabilities - Automate security testing and integrate into CI/CD pipelines - Conduct third-party security audits and assessments - Enhance data protection with field-level encryption and geo-obfuscation **Dependencies:** - Completion of enhanced authentication and access controls #### Phase: LONG-TERM **Timeline:** 6-12 months **Rationale:** Strategic initiatives aimed at achieving long-term security maturity and integrating cutting-edge technologies for continuous improvement. **Controls to Implement:** - Develop a comprehensive security awareness and training program - Integrate AI/ML-based security controls for proactive threat detection - Conduct comprehensive penetration testing and red team exercises - Establish a robust incident response readiness program **Dependencies:** - Completion of advanced threat detection and security testing automation #### Phase: ONGOING **Timeline:** Continuous **Rationale:** These activities ensure the platform maintains a strong security posture and responds effectively to new threats and compliance requirements. **Controls to Implement:** - Continuous security monitoring and threat intelligence - Regular patch management and vulnerability remediation - Compliance audits and regulatory updates - Incident response and recovery exercises **Dependencies:** - Ongoing updates to security and compliance frameworks ### 10.3. Resource Requirements Skills: Security engineers, Security architects, Web developers, Compliance specialists; Recommended tools: SIEM solutions for logging and monitoring, Vulnerability scanners for testing, Encryption libraries for data protection, API management tools for secure interfaces; Estimated time effort: Approximately 3-6 months for initial phases, with ongoing efforts extending resources as per system complexity and requirements. --- ## 11. Verification and Testing Strategy ### 11.1. Testing Approach Integrate security testing throughout the software development lifecycle (SDLC) with an emphasis on continuous security practices. Balance automated scanning with manual evaluations to prioritize high-risk areas based on business impact, adhering to shift-left security principles by incorporating security testing earlier and continuously. This approach ensures that vulnerabilities are identified and resolved before they reach production, reducing overall risk and improving compliance with regulations. ### 11.2. Testing Methods | Method | Frequency | Tools | |----------------------------------------------------|--------------------------|-------------------------------------------------| | STATIC APPLICATION SECURITY TESTING (SAST) | Every commit/build | SonarQube, Semgrep, Checkmarx, CodeQL | | DYNAMIC APPLICATION SECURITY TESTING (DAST) | Nightly/weekly | OWASP ZAP, Burp Suite, Acunetix | | DEPENDENCY SCANNING | Every build | Snyk, Dependabot, OWASP Dependency-Check | | SECRETS SCANNING | Every commit | TruffleHog, GitLeaks, GitHub Secret Scanning | | CONTAINER/INFRASTRUCTURE SCANNING | Every deployment | Trivy, Clair, Prowler, ScoutSuite | | PENETRATION TESTING | Quarterly or before major releases | Custom scripts, Metasploit, Burp Suite Pro | | SECURITY CODE REVIEW | For critical features | GitHub/GitLab code review, security checklists | | COMPLIANCE SCANNING | Continuous | AWS Config, Azure Policy, Cloud Custodian | ### 11.3. Compliance Verification Multi-standard compliance (OWASP ASVS, NIST SP 800-53, ISO 27001) will be verified through automated tools and manual checks against regulatory requirements such as GDPR, CCPA, and PCI-DSS. Audit preparation will involve ensuring documentation and evidence collection for external audits, including logs, assessments, and compliance checklists. Recommendations will include engaging third-party auditors for comprehensive evaluations to verify adherence to all applicable legislation and best practices. ### 11.4. Continuous Monitoring Implement Security Information and Event Management (SIEM) for real-time monitoring, supported by Intrusion Detection/Prevention Systems (IDS/IPS) to identify and mitigate threats. All logs will be aggregated and analyzed for anomalies, with integration into incident response processes to ensure prompt action against security events. This will facilitate continuous threat assessment and improve the organization’s ability to respond to incidents effectively. ### 11.5. Key Performance Indicators (KPIs) - Mean time to detect (MTTD) security issues - Mean time to remediate (MTTR) vulnerabilities - Percentage of critical vulnerabilities patched within SLA - Security test coverage percentage - False positive rate in automated scanning - Compliance audit pass rate ### 11.6. Mapping Testing Methods to Security Controls | Testing Method | Security Controls (OWASP ASVS, NIST SP 800-53, ISO 27001) Verified | |--------------------------------------------------|---------------------------------------------------------------------| | STATIC APPLICATION SECURITY TESTING (SAST) | Input validation, authentication, authorization, cryptographic protections, hardcoded secrets | | DYNAMIC APPLICATION SECURITY TESTING (DAST) | Authentication, authorization, XSS, CSRF, SQL injection, session management | | DEPENDENCY SCANNING | Supply chain security, vulnerability management | | SECRETS SCANNING | Cryptographic protection, secrets management | | CONTAINER/INFRASTRUCTURE SCANNING | Configuration management, infrastructure security | | PENETRATION TESTING | All high-risk controls, business logic integrity | | SECURITY CODE REVIEW | Authentication, authorization, cryptographic implementations, data protection | | COMPLIANCE SCANNING | All compliance-related controls, auditing, access controls | This comprehensive security verification and testing strategy is designed to ensure a robust security posture throughout the software development lifecycle and maintain compliance with applicable regulations. --- ## 12. Validation Report This section presents a comprehensive validation of the security requirements generated throughout this analysis. The validation evaluates the requirements against five key dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. This assessment ensures that the security requirements are comprehensive, technically sound, and actionable for implementation teams. ### 12.1. Overall Assessment The overall validation score reflects the quality and completeness of the security requirements across five critical dimensions. Each dimension is scored from 0.0 to 1.0, with 1.0 representing excellent coverage and 0.0 indicating significant gaps. **Overall Score:** 0.88/1.0 **Validation Status:** ✅ PASSED The security requirements have met the quality threshold (≥0.8) and are ready for implementation. The requirements demonstrate comprehensive coverage, technical accuracy, and alignment with business objectives. The validation assesses: - **Completeness**: Are all identified security concerns adequately addressed? - **Consistency**: Do requirements align with each other without contradictions? - **Correctness**: Are controls appropriate for the identified risks and correctly applied? - **Implementability**: Are requirements specific, actionable, and feasible to implement? - **Alignment**: Do security requirements align with business requirements and objectives? ### 12.2. Dimension Scores | Dimension | Score | Status | |-----------|-------|--------| | Completeness | 0.80 | ✅ | | Consistency | 0.95 | ✅ | | Correctness | 0.90 | ✅ | | Implementability | 0.80 | ✅ | | Alignment | 0.95 | ✅ | **Score Interpretation:** - ✅ 0.8-1.0: Excellent - ⚠️ 0.7-0.79: Acceptable (minor improvements needed) - ❌ <0.7: Needs significant improvement ### 12.3. Detailed Feedback Summary The provided security requirements and control mappings give strong, broad coverage across authentication, authorization, privacy, moderation, geo-privacy, payments, logging, and AI/ML concerns. They align well with the business needs for a geo-centric student-housing platform and map to appropriate standards (OWASP, NIST, ISO27001). However, several areas need clarification, additional coverage, or more prescriptive acceptance criteria to make the requirements fully implementable and to close risk gaps. Actionable improvements (prioritised) 1) Add explicit API and web application security controls (high priority) - Specify CSRF protection, cookie policies (Secure, HttpOnly, SameSite), CORS allowlist rules, and OAuth2/OpenID Connect or SAML support if third-party SSO is required. Acceptance criteria: per-endpoint tests demonstrating CSRF tokens and cookie flags, and an SSO integration test plan. - Define API gateway responsibilities: authentication, authorization enforcement, rate limiting, request throttling, request size limits, and request/response schema validation. Acceptance criteria: gateway policies documented and automated tests proving enforcement. - Include WAF and OWASP Top 10 testing in security gates (DAST) and SAST in CI. Acceptance criteria: DAST/SAST baseline results with remediation plan and tracked CVE/issue closure. 2) Strengthen secrets, key, and credential management (high priority) - Mandate centralized KMS/HSM usage for application keys, encryption keys, and API credentials, with automated rotation policies and RBAC for key administrators. Acceptance criteria: KMS configured, rotation schedule documented and demonstrable, role separation in place. - Add guidance to avoid storing long-lived credentials on mobile devices and to use short-lived tokens with refresh-token rotation and revocation. Acceptance criteria: refresh token rotation implemented and revocation test passes. 3) Expand anti-abuse, fraud, and availability controls (high priority) - Define DoS/DDoS mitigations, WAF rules, scaling/auto-scaling plans, and rate limits by endpoint/type (search, alerts, messaging). Include abuse detection for bulk account creation and alerting pipelines. Acceptance criteria: simulated traffic tests showing graceful degradation and auto-scaling, rate-limit tests. - Add account takeover detection: anomalous login detection, device fingerprinting, IP risk scoring, and mandatory MFA for high-risk actions. Acceptance criteria: ATM detection rules and step-up authentication tests. 4) Make AI/ML governance concrete (high priority) - For the automated moderation, search ranking, and NLP components add a Model Governance control set: model cards, versioning, change control for models, training-data provenance, PII scrubbing from training sets, evaluation metrics, adversarial robustness testing, and rollback procedures. Acceptance criteria: model cards present, versioned deployments with canary rollout tests, documented training data provenance and PII removal checks. - Add continuous monitoring for model performance/drift (false positive/negative rates) and an incident playbook when models degrade. Acceptance criteria: monitoring dashboards and alert thresholds defined for drift and accuracy. 5) Improve privacy-by-design specifics for geolocation and PII (high priority) - Define the exact technique and granularity for approximate locations (e.g., grid size or geohash precision). Specify minimum aggregation thresholds for map clustering to avoid deanonymization. Acceptance criteria: tests confirming no exact coordinates are returned and that de-anonymization risk analysis passes. - Specify retention windows for adverts, messages, and logs and align them with DSAR/ROPA. Acceptance criteria: retention policy documented and deletion/archive jobs tested. 6) Make logging, monitoring, and incident response operational (high priority) - Define log retention periods, encryption of logs, append-only storage or WORM, separation of duties for log access, and SIEM alerting playbooks. Acceptance criteria: SIEM rules documented, access controls for log stores demonstrated, and sample incidents run through the playbook. - Provide incident response SLAs and escalation paths for abuse reports, data breaches, and paid-tier disputes. Acceptance criteria: playbooks and runbook drills with lessons learned. 7) Payment and PCI scope tightening (high priority) - Emphasize using PSP tokenization to keep PAN out of platform systems. Add PCI-specific requirements (SAQ or attestation) and periodic PCI scans/assessments. Acceptance criteria: no PAN stored in logs/databases, Payment flows pass PSP and PCI attestations. 8) Add supply-chain, third-party, and mobile-specific controls (medium priority) - Add supply-chain controls for third-party libraries, map providers, and NLP/ML providers (SBOM, dependency scanning, third-party risk assessment). Acceptance criteria: SBOM present and dependency scanning configured in CI. - For mobile: define secure local storage, certificate pinning (where appropriate), jailbreak/root detection, and secure update channels for mobile apps. Acceptance criteria: mobile hardening checklist and tests passing on supported device matrix. 9) Make requirements measurable and testable (medium priority) - For each control include acceptance criteria: who is owner, test method (unit/integration/pen-test), pass/fail criteria, and expected logging/metrics. Example: “MFA required for admin logins; test: attempt admin login without MFA — expected: denied; evidence: auth logs show step-up event.” 10) Improve AI/ML security specifics for prompt injection and data leakage (medium priority) - Provide concrete mitigations: input sanitization libraries, guarded prompt templates, output filters, rate limits on model queries, and data retention policies for prompts/responses. Acceptance criteria: fuzz/prompt-injection tests passing and prompt logs redaction verified. Other suggested clarifications and minor fixes - Clarify DSAR response timelines, default consent legal bases (contractual/legit interest), and how consent withdrawal is implemented (propagation latency). Add measurable SLA targets. - Explicitly state “never log sensitive fields” (e.g., full email, phone, PAN) or require redaction in logs with examples. - Add a backup & restore / disaster recovery requirement (RTO/RPO targets) especially for critical data (user profiles, payments ledger, audit logs). - Provide a mapping of high-risk endpoints to required testing cadence (SAST: weekly on CI, DAST: monthly, Pen Test: annual or after major release). - For moderation, add integrity and privacy controls for stored evidence (images, messages) and retention rules for investigation data. Why these changes matter - They close operational gaps (API security, key management, DDoS), reduce legal/compliance risk (PCI, GDPR), and make AI controls actionable and auditable. They also convert high-level guidance into developer-testable acceptance criteria so implementation and validation are practical. Recommended next steps (concrete) 1. Update requirements document to include the missing controls above and attach acceptance criteria per control. 2. Create a prioritized implementation backlog covering the high-priority items (API gateway, secrets/KMS, model governance, CSRF/cookie policy, DDoS and rate-limits, PCI tokenization). 3. Define owners for each control and a verification plan (unit/integration tests, SIEM rules, pen tests) with timelines. 4. Run a threat-modeling workshop focused on geo-deanonymization and ML adversarial threats and update controls accordingly. 5. Deliver a compliance mapping artifact that ties each control to GDPR/PCI/CCPA/COPPA obligations and evidence required for audits. If you want, I can produce: (a) a prioritized backlog of the specific changes with user stories and acceptance criteria; (b) example test cases for the highest-risk controls (API gateway, MFA, KMS, ML governance); or (c) a concrete geolocation anonymization spec (grid size recommendations and deanonymization analysis). --- ## Appendix A: Original Requirements Document ``` Student Household Vacancy Platform Requirements We need to build a geo-centric platform for advertising and discovering vacancies in student households (sharehouses) and for finding potential housemates. The system will prioritise location-based information while ensuring user security and privacy. Key Features: 1. User Management Account creation and secure login. User profiles with role assignments (Advertiser, Seeker, Moderator, Administrator). Email domain filtering for free-tier advertisers (e.g., only university email addresses). Paid-tier access for agencies, hostels, and temporary accommodation providers. 2. Advert Management Submit, edit, and delete adverts for properties and rooms. Each property can include multiple rooms with individual details (cost, size, availability). Automatic filtering and moderation system to detect spam and malicious content before publication. Adverts are not immediately active; require approval by moderators or automated checks. Rich advert details including: Location (approximate, not exact address for security). Room specifications (size, furnishings, amenities, cost, deposit). Household preferences (smoking, pets, occupation, age range, language, vegetarian preference). Availability dates and minimum/maximum stay. Bills and broadband inclusion. 3. Search and Filtering Geo-centric search with approximate location visualisation (e.g., neighbourhood or postcode area). Advanced filters: price range, distance from a specific point, number of housemates, amenities, stay duration. Ability to save filter sets and searches. Email alerts for new adverts matching saved criteria (daily digest and instant notifications). 4. Favourites and Personalisation Users can “favourite” properties or rooms. Generate a personalised summary list of saved adverts. Option to manage and organise favourites within the user dashboard. 5. Collaboration and Communication Secure in-app messaging between advertisers and seekers. No direct contact details displayed publicly; communication mediated through the platform. Optional display of phone number/email for verified users. 6. Visualisation Interactive map showing approximate locations of properties. Clustered view for areas with multiple adverts. No exact addresses displayed, only general vicinity, for general safety of advertises. 7. Notifications Email notifications for saved searches and favourites. In-app notifications for advert status changes (approved, expired, updated). Alerts for messages and responses. 8. Control System Administrator and moderator dashboard for: - Approving, disabling, or deleting adverts. - Managing user accounts and roles. - Reviewing flagged content and handling disputes. Automated moderation tools for detecting inappropriate content and spam. Reporting system for users to flag suspicious adverts. Automatically remove expired adds. 1. Paid Tier Premium advertising options for agencies, hostels, and temporary accommodation providers. Features for paid tier: Priority listing and enhanced visibility. Ability to include branding and extended descriptions. Analytics dashboard for advert performance. Secure payment gateway integration for subscription and one-off payments. 10. Security and Privacy Approximate location display to protect user privacy. Verification of email domains for free-tier advertisers. GDPR-compliant data handling and storage. 11. Platform Accessibility: The application will be accessible via web browser and optimised for mobile devices. It will store user data, advert details, location metadata, and communication logs securely. ``` --- ## Appendix B: Glossary | Term | Definition | |------|------------| | ASVS | Application Security Verification Standard (OWASP) | | STRIDE | Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege | | SAST | Static Application Security Testing | | DAST | Dynamic Application Security Testing | | MFA | Multi-Factor Authentication | | RBAC | Role-Based Access Control | | PII | Personally Identifiable Information | | PHI | Protected Health Information | | GDPR | General Data Protection Regulation | | HIPAA | Health Insurance Portability and Accountability Act | | PCI-DSS | Payment Card Industry Data Security Standard | --- ## Appendix C: Complete Threat List This appendix contains the complete list of all identified threats with full descriptions and mitigation strategies. Threats are organized by risk level for easy reference. ### Critical Risk Threats **THR-001** - Frontend Layer - **Category:** Information Disclosure - **Likelihood:** High | **Impact:** High - **Risk Level:** Critical - **Description:** Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content, favourites, or saved searches causing session token theft, account takeover, or exfiltration of PII from pages rendered in other users' browsers. - **Mitigation Strategy:** Apply strict output encoding/escaping for all user content, use a secure templating engine, implement Content Security Policy (CSP) restricting script sources, sanitize HTML with a safe whitelist or disallow HTML, mark session cookies HttpOnly and SameSite=strict; conduct automated and manual security testing (SAST/DAST). **THR-006** - Application Services (Auth/RBAC) - **Category:** Spoofing - **Likelihood:** High | **Impact:** High - **Risk Level:** Critical - **Description:** Credential stuffing, weak password reuse, or brute-force attacks leading to account takeover for advertisers or moderators. Email domain filtering for free-tier may be bypassed using disposable or compromised university addresses. - **Mitigation Strategy:** Implement rate-limited login attempts, account lockouts with progressive delays, MFA (mandatory for moderators/admins and encouraged for advertisers), password strength policy, monitor for credential stuffing via IP reputation and breached-password checks; verify university domain via domain MX checks and time-limited email verification tokens. ### High Risk Threats **THR-002** - Frontend Layer - **Category:** Tampering - **Likelihood:** High | **Impact:** Medium - **Risk Level:** High - **Description:** Client-side manipulation of UI (e.g., modifying JS to change advert metadata, prices, or display premium features) and submitting forged requests that rely on client-side checks (price, entitlements). - **Mitigation Strategy:** Enforce server-side authorization and validation for all business-critical operations (price changes, entitlement checks). Sign client-visible configuration where needed, validate inputs on server, and log suspicious client-side anomalies. **THR-004** - Edge Layer (CDN/WAF/API Gateway) - **Category:** Denial of Service - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Layer 7 volumetric or application-layer DDoS targeting search, messaging, or advert submission endpoints to degrade availability and impact revenue and user confidence. - **Mitigation Strategy:** Use CDN + WAF with adaptive rate-limiting and geo-blocking, API Gateway throttling per IP and per-account, autoscaling backend, CAPTCHA for suspicious flows (advert creation), traffic anomaly detection and scrubbing service. **THR-005** - Edge Layer (API Gateway) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Replay attacks or token theft in transit due to inadequate transport security or poor token handling (long-lived tokens, insecure storage on client) leading to account hijacking. - **Mitigation Strategy:** Enforce TLS 1.2+/HSTS, short-lived access tokens with refresh tokens stored securely, require token binding if possible, use OAuth 2.0 best practices, revoke tokens on suspicious activity, secure local storage (avoid persistent tokens in localStorage), implement device/session fingerprinting and MFA for sensitive actions. **THR-007** - Application Services (Auth/RBAC) - **Category:** Elevation of Privilege - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Broken access control allowing privilege escalation (e.g., seeker modifies request to set 'role=moderator' or uses API endpoints reserved for admin to approve adverts). - **Mitigation Strategy:** Enforce server-side RBAC checks for every sensitive endpoint, implement deny-by-default ACLs, use centralized authorization library, detailed audit logging of role changes, review admin endpoints manually and require MFA/SSO for admin actions. **THR-008** - Application Services (Core API/Search/Geo) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Exposure of exact addresses or PII via search index or API responses (e.g., detailed coordinates leaked in map tile queries or in metadata exposed in API), undermining privacy requirement of approximate locations. - **Mitigation Strategy:** Implement server-side fuzzing/geo-obfuscation before storing/searching; strip exact coordinates from public search results, only store precise addresses encrypted and available to authorized parties, review third-party map integrations so they only receive approximate coordinates, log and monitor access to precise location fields. **THR-009** - Application Services (Moderation Pipeline) - **Category:** Tampering - **Likelihood:** High | **Impact:** Medium - **Risk Level:** High - **Description:** Adversarial content engineered to bypass automated moderation (image/text obfuscation, alternate language, unicode tricks) leading to publication of spam, scams, or malicious adverts. - **Mitigation Strategy:** Use layered moderation: ML heuristics + deterministic rules + human review for flagged or high-risk adverts; adversarial testing of moderation models; limit feature exposure for new/low-reputation advertisers; rate-limit advert creation. **THR-010** - Application Services (Messaging) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** In-app moderated messaging used to exchange PII; messages stored in DB and in transit may be exposed due to weak encryption, improper RBAC, or logging of message bodies to analytics systems. - **Mitigation Strategy:** Encrypt messages at rest with KMS-managed keys, enforce TLS in transit, restrict access to message stores to smallest set of service accounts, redact PII in analytics pipelines, provide ephemeral message retention policies and user-controlled deletion, log only metadata not message contents. **THR-012** - Data Storage (Relational DB / Search Index) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Unauthorized access to backups, snapshots, or misconfigured search index (Elasticsearch/OpenSearch) exposing full dataset including PII or sensitive adverts. - **Mitigation Strategy:** Enforce network-level access controls (VPC, private endpoints), enable authentication and TLS on search services, encrypt backups at rest, rotate access keys, restrict snapshot exports, and monitor/access alerts for unusual data exports. **THR-015** - External Services (Payment Gateway) - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Payment flow manipulation or token interception causing fraudulent premium listings, subscription status manipulation, or chargeback/fraud against the platform. - **Mitigation Strategy:** Use PCI-compliant gateway with tokenization (never store raw card data), validate webhooks with signatures, verify payment notification origins, reconcile subscription state server-side, implement fraud detection and anomaly monitoring, require 3DS where supported. **THR-017** - Admin & Moderation - **Category:** Elevation of Privilege - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Compromise of admin/moderator accounts via phishing or weak SSO config leading to mass approval of malicious adverts, deletion or tampering with audit logs, or user bans. - **Mitigation Strategy:** Use strong SSO with MFA, enforce least privilege for moderator roles (separation of duties), require justification and second approval for bulk actions, record all admin actions to immutable audit logs, and monitor for anomalous admin activity. **THR-019** - Notifications & Messaging (In-app) - **Category:** Denial of Service - **Likelihood:** High | **Impact:** Medium - **Risk Level:** High - **Description:** Messaging system spam or automated bots overwhelm a user's inbox or notification system causing resource exhaustion and poor UX; attackers may use messaging to send harmful links. - **Mitigation Strategy:** Rate-limit message sending per account/IP, implement reputation scoring for senders, CAPTCHAs on account actions, automated content filtering, allow users to block/report senders, throttle notifications and use backpressure in queueing system. **THR-021** - External Services (Email Provider) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** High - **Risk Level:** High - **Description:** Compromise or misconfiguration at the email provider leading to leakage of verification emails, digests, or password resets enabling account takeover or exposure of PII. - **Mitigation Strategy:** Use reputable ESP with secure contracts, enable TLS and DKIM/SPF/DMARC, minimize sensitive data in emails, send reset links that expire quickly, monitor ESP security advisories, and have incident response plan for ESP compromise. **THR-022** - Data Storage (Backups & Logs) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Backups or audit logs containing historic PII retained longer than necessary, or accessible by excessive staff, leading to compliance violations (GDPR) and data breach risks. - **Mitigation Strategy:** Apply data retention policies and automated deletion, anonymize/pseudonymize PII where possible, restrict access to backups via IAM, encrypt backups, and periodically audit access to retention stores. **THR-023** - Frontend / Edge (CDN) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** High - **Risk Level:** High - **Description:** Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pages cached publicly) exposing PII or private adverts to other users. - **Mitigation Strategy:** Use cache-control headers to prevent caching of personalized content, vary cache on headers appropriately, use CDN configuration to strip sensitive cookies/headers, and test CDN caching rules for unintended caching. **THR-024** - Application Services / API - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Injection attacks (SQL injection or NoSQL injection) via poorly validated advert fields or search parameters allowing data tampering, unauthorized data access, or remote code execution via unsafe ORM usage. - **Mitigation Strategy:** Use parameterized queries/ORM safe APIs, validate and constrain inputs (length/format), ORM prepared statements, adopt least-privilege DB accounts, run regular SAST/DAST and DB access monitoring, and protect admin endpoints behind stricter controls. **THR-027** - External Services (Third-party Integrations overall) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Over-sharing of PII to third-party analytics, logging, or ML moderation providers (sending full message bodies or exact addresses) creating compliance and privacy risk. - **Mitigation Strategy:** Data minimization: pseudonymize or aggregate before sending, use contracts and DPA with providers, vet security posture of providers, encrypt data in transit and at rest, and implement strict access controls on provider integrations. **THR-029** - Infrastructure / Cloud - **Category:** Tampering - **Likelihood:** Medium | **Impact:** High - **Risk Level:** High - **Description:** Cloud misconfigurations (open management ports, overly permissive IAM roles, publicly exposed DB or storage) allowing attackers to access or modify data and resources. - **Mitigation Strategy:** Implement IaC with security scanning, enforce least-privilege IAM, use VPC/private endpoints, rotate credentials, use cloud provider security posture management (CSPM), run periodic pen tests and configuration audits, and enable multi-account separation for prod/staging. ### Medium Risk Threats **THR-003** - Frontend Layer - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** UI-level phishing via malicious adverts or profiles that mimic platform branding to trick users into revealing credentials or off-platform contact details. - **Mitigation Strategy:** Restrict HTML/branding in adverts, enforce a platform watermark and verified-badge UI for verified advertisers, run automated moderation for suspicious branding, user education and reporting flow, and block off-platform contact until verification. **THR-011** - Notifications & Messaging (Email/Push Providers) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Sensitive information leaked via email digests or push notifications (e.g., full advert addresses, private messages) or email interception due to misconfigured email provider templates exposing PII. - **Mitigation Strategy:** Limit content in notifications to non-sensitive summaries, avoid including PII or exact location in emails/pushes, use secure provider configurations (TLS for SMTP, signed DKIM/SPF), allow users to opt-out of email content sharing, and review templates for accidental leakage. **THR-013** - Data Storage (Object Storage for Media) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Publicly accessible S3/Blob containers containing photos that include metadata or people could be exposed due to incorrect ACLs or predictable object URLs. - **Mitigation Strategy:** Use private buckets with signed, time-limited URLs for media access, strip EXIF/GPS metadata from uploaded photos, scan uploads for sensitive content, enforce upload size/content checks, and set least-privilege IAM policies for storage access. **THR-014** - External Services (Maps API) - **Category:** Information Disclosure - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Third-party map provider logs or telemetry reveal approximate queries or leak location metadata (e.g., passing exact coords), or attacker abuses API keys embedded in frontend to query map endpoints for data enumeration. - **Mitigation Strategy:** Send only obfuscated/approximate coordinates to map provider, restrict API keys via referer/IP restrictions, avoid embedding privileged keys in client, use server-side map proxy for sensitive queries, review provider's privacy SLA. **THR-016** - Payments & Billing - **Category:** Repudiation - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Advertisers dispute charges or claim service not delivered; lack of reliable invoice/transaction audit trail hinders dispute resolution and may lead to financial loss. - **Mitigation Strategy:** Maintain tamper-evident audit logs for billing events, store payment tokenization metadata, send receipts with transaction IDs, enable immutable logs in SIEM, and retain reconciliation records per compliance retention policies. **THR-018** - Admin & Moderation - **Category:** Repudiation - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Insufficient or tamperable audit logs allowing admins/moderators to deny or hide actions (e.g., disabling adverts without reason), impacting incident response and compliance. - **Mitigation Strategy:** Use append-only, write-once audit logging (cloud-native immutability), forward logs to SIEM with restricted access, implement logging integrity checks, and enforce log retention/rotation policies for compliance. **THR-020** - Application Services (Search/Geo) - **Category:** Tampering - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Search index poisoning or malicious adverts crafted to manipulate search ranking (e.g., SEO spam, repeated adverts to surface malicious listings), reducing quality and user trust. - **Mitigation Strategy:** Rate-limit advert creation, use deduplication checks, reputation-based ranking and human review for new advertisers, monitor ranking changes, and use anomaly detection in search metrics. **THR-025** - Application Services (API) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** API key leakage or abuse (e.g., frontend-embedded keys used to query private endpoints or enumerate adverts), enabling attackers to harvest data or bypass quotas. - **Mitigation Strategy:** Never embed privileged keys in frontend, restrict keys by origin/IP and scope, rotate keys regularly, monitor key usage and set quotas, and require server-side calls for privileged operations. **THR-026** - Payments & Billing - **Category:** Repudiation - **Likelihood:** Low | **Impact:** Medium - **Risk Level:** Medium - **Description:** Lack of immutable proof for subscription entitlement changes leads to disputes where advertisers claim upgrades/downgrades were not applied correctly or were fraudulent. - **Mitigation Strategy:** Record subscription lifecycle events immutably with timestamps, require server-side confirmation flows for entitlements, keep audit trails tied to payment gateway transaction IDs, and notify users on entitlement changes. **THR-028** - Platform-wide (Account Creation & Email Domain Filtering) - **Category:** Spoofing - **Likelihood:** Medium | **Impact:** Medium - **Risk Level:** Medium - **Description:** Bypass of email-domain verification for free-tier advertisers using disposable university-like addresses or compromised student mailbox leading to fraudulent adverts. - **Mitigation Strategy:** Perform MX record checks and restrict to known university domains list, implement additional checks (SAML/IdP integration with select institutions), manual/automated scrutiny for new advertiser accounts, rate-limit new accounts, and use reputation scoring before granting free-tier privileges. **THR-030** - Platform-wide (Search & Saved Searches / Alerts) - **Category:** Information Disclosure - **Likelihood:** Low | **Impact:** Medium - **Risk Level:** Medium - **Description:** Saved searches and alert digest emails could be inferred by attackers to profile a user's activity or to stalk users (e.g., frequent queries for a person's name or location patterns). - **Mitigation Strategy:** Protect saved search metadata with proper ACLs, encrypt saved filters in DB if sensitive, allow users to opt-out of instant alerts, aggregate digest emails, and rate-limit alerts per user to prevent metadata leakage. **Total Threats:** 30 --- ## Appendix D: Complete Requirements Traceability Matrix This appendix provides complete end-to-end traceability from requirements through threats to controls and verification. ### Full Traceability Table | Req ID | Requirement | Category | Sensitivity | Threat IDs | Security Controls | Priority | Verification | Status | |--------|-------------|----------|-------------|------------|----------------|----------|--------------|--------| | REQ-001 | User registration and secure login with role assig... | Authentication & Authorization | High | THR-001, THR-003, THR-004 +7 | [OWASP] V2.1.1, [OWASP] V4.1.1, [NIST] IA-2 +1 | Critical | Review access provisioning SOPs, sampling of access requests, and RBAC review records., Inspect identity provider configuration, review auth logs, and perform positive/negative login tests. | Pending | | REQ-002 | Email domain verification for free-tier advertiser... | Account Management & Verification | High | THR-006, THR-011, THR-016 +4 | [OWASP] V2.2.3, [OWASP] V4.2.1, [NIST] AC-2 +1 | Critical | Review service access configurations and test unauthorized access attempts., Review authorization policies and test scenarios for free vs paid users. | Pending | | REQ-003 | User profile management capturing display name, pr... | Data Management / Privacy | Medium | THR-001, THR-002, THR-003 +7 | [ISO27001] A.18.1.4, [OWASP] V1.4.3, [NIST] AC-6 +1 | Critical | Access tests for different roles and review of API authorization rules., Design review and UX testing of privacy controls; data inventory check for minimization. | Pending | | REQ-004 | Advert lifecycle management: create, save draft, s... | Content Management | Medium | THR-001, THR-002, THR-003 +7 | [OWASP] V4.2.2, [NIST] AC-3, [OWASP] V5.1.3 +1 | Critical | Policy review and data-layer query inspection for authorization predicates., Unit/integration tests for owner vs non-owner scenarios; code review of authorization checks. | Pending | | REQ-005 | Support property-level entry with multiple room en... | Data Model & Catalog | Low | THR-004, THR-022 | None | Medium | Manual Review | Pending | | REQ-006 | Automatic moderation/ filtering pipeline using heu... | Moderation & Safety | High | THR-001, THR-002, THR-003 +7 | None | Medium | Manual Review | Pending | | REQ-007 | Moderator and Administrator dashboard to review, a... | Administration & Governance | High | THR-001, THR-003, THR-004 +7 | [OWASP] V4.1.3, [NIST] AC-5, [ISO27001] A.9.2.6 +1 | Critical | Audit event catalog review and sampling of admin action logs., Review role definitions and evidence of dual-control workflows. | Pending | | REQ-008 | Geo-centric search with approximate location visua... | Search & Discovery | Low | THR-001, THR-004, THR-008 +5 | [OWASP] V1.4.2, [OWASP] V9.4.1, [NIST] PL-8 +1 | High | Review security architecture documents and threat models covering geo components., Review data model and retention jobs; verify only approximate location is exposed. | Pending | | REQ-009 | Advanced filters: price range, distance, number of... | Search & Personalisation | Low | THR-001, THR-002, THR-004 +6 | None | Medium | Manual Review | Pending | | REQ-010 | Email alerts (instant and daily digest) and in-app... | Notifications & Engagement | Medium | THR-001, THR-002, THR-003 +7 | [OWASP] V10.4.1, [OWASP] V5.4.3, [NIST] SI-4 +1 | High | Review rate limit configurations and simulate high-frequency alert creation., Check monitoring rules and SIEM dashboards for alerting subsystem. | Pending | | REQ-011 | Favourites/bookmarks management: allow users to fa... | User Experience & Personalisation | Low | THR-001, THR-003, THR-007 +5 | [OWASP] V4.3.1, [NIST] AC-16, [ISO27001] A.9.4.1 +1 | Critical | Policy review and functional testing of access restrictions., Review storage encryption and access controls; test for tampering resistance. | Pending | | REQ-012 | Secure in-app messaging system that mediates commu... | Communication & Privacy | High | THR-001, THR-002, THR-003 +7 | [OWASP] V9.2.1, [NIST] SC-13, [OWASP] V2.8.1 +1 | Critical | Review cipher suites and test integrity verification on message transport., TLS configuration scan and packet inspection to confirm encryption. | Pending | | REQ-013 | Interactive map view using third-party mapping API... | Data Privacy & Visualisation | Medium | THR-001, THR-002, THR-006 +7 | [OWASP] V1.4.1, [OWASP] V5.3.1, [NIST] SC-7 +1 | High | Network configuration review and monitoring of egress to mapping services., Design review and UI tests to confirm only approximate positions are shown. | Pending | | REQ-014 | Reporting and abuse-flagging workflow for users to... | Safety & Trust | High | THR-001, THR-003, THR-006 +7 | [NIST] AU-3, [OWASP] V7.1.1, [ISO27001] A.12.4.1 +1 | High | Check logging configuration and attempt to access logs with different roles., Inspect SIEM dashboards and alert configurations for moderation events. | Pending | | REQ-015 | Paid-tier features: priority listing / boosted pla... | Monetisation & Analytics | Medium | THR-003, THR-010, THR-015 +3 | [OWASP] V4.2.3, [OWASP] V10.4.3, [NIST] AU-2 +1 | Critical | SOP review and training records., Attempt to access premium features with non-paid accounts; review authorization middleware. | Pending | | REQ-016 | Secure payment processing via a PCI-DSS-compliant ... | Payment Processing & Compliance | High | THR-001, THR-003, THR-004 +7 | [OWASP] V9.2.2, [OWASP] V9.3.2, [ISO27001] A.15.1.1 +1 | Critical | TLS scan and connection tests to PSP endpoints; review client configuration., Third-party risk assessment records and periodic reassessment reports. | Pending | | REQ-017 | GDPR-compliant data handling: obtain explicit cons... | Legal & Privacy | High | THR-002, THR-007, THR-008 +7 | [ISO27001] A.18.1.4, [OWASP] V1.4.4, [NIST] AR-8 +1 | Critical | Examine consent records and test withdrawal propagation to processing systems., Review disclosure log schema and perform a test DSAR. | Pending | | REQ-018 | Logging, monitoring and audit trails for authentic... | Security Operations & Forensics | High | THR-007, THR-009, THR-014 +7 | [OWASP] V7.1.3, [NIST] AU-8, [ISO27001] A.12.4.2 +1 | Critical | Log sampling and SIEM ingestion verification for all target event types., Inspect log storage controls and integrity check outcomes. | Pending | | REQ-019 | Security controls including encryption in transit ... | Application Security | High | THR-005, THR-007, THR-010 +7 | [OWASP] V9.1.2, [NIST] SC-12, [OWASP] V2.7.5 +1 | Critical | Code review of validation and gateway configs; fuzz testing of endpoints., Review data inventory and control mappings to classification levels. | Pending | | REQ-020 | Accessibility and responsive design to support com... | Accessibility & UX | Low | THR-001, THR-003, THR-004 +7 | [OWASP] V1.3.1, [OWASP] V7.3.1, [ISO27001] A.14.2.1 +1 | Low | UX review of error messages and accessibility testing., Policy review and pipeline checks for accessibility/security gates. | Pending | **Total Requirements Tracked:** 20 ### Detailed Requirement Mappings The following section provides detailed traceability for each requirement: #### REQ-001: User registration and secure login with role assignment (Advertiser, Seeker, Moderator, Administrato... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-005**: Replay attacks or token theft in transit due to inadequate transport security or... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - *...and 5 more threats* **Security Controls:** - **[OWASP] V2.1.1**: [OWASP] Verify that user registration and login mechanisms require robust authentication... - **[OWASP] V4.1.1**: [OWASP] Verify that a role-based access control (RBAC) or attribute-based access control... - **[NIST] IA-2**: [NIST] Identify and authenticate organizational users (and/or processes acting on behal... - **[ISO27001] A.9.2.3**: [ISO27001] The provisioning of user access rights shall be formalized, including assignment... **Verification:** Review access provisioning SOPs, sampling of access requests, and RBAC review records., Inspect identity provider configuration, review auth logs, and perform positive/negative login tests., Review auth flow design, inspect password storage configuration, and test registration/login including account lifecycle., Policy review, code inspection of authorization middleware, and role-based access tests. **Priority:** Critical | **Status:** Pending --- #### REQ-002: Email domain verification for free-tier advertisers (restrict to institutional/university email doma... **Related Threats:** - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-011**: Sensitive information leaked via email digests or push notifications (e.g., full... - **THR-016**: Advertisers dispute charges or claim service not delivered; lack of reliable inv... - **THR-021**: Compromise or misconfiguration at the email provider leading to leakage of verif... - **THR-026**: Lack of immutable proof for subscription entitlement changes leads to disputes w... - *...and 2 more threats* **Security Controls:** - **[OWASP] V2.2.3**: [OWASP] Verify that the application verifies the ownership of an email address or phone ... - **[OWASP] V4.2.1**: [OWASP] Verify that access controls enforce authorization decisions based on the authent... - **[NIST] AC-2**: [NIST] Manage information system accounts, including establishing, activating, modifyin... - **[ISO27001] A.9.1.2**: [ISO27001] Users shall only be provided with access to the network and network services tha... **Verification:** Review service access configurations and test unauthorized access attempts., Review authorization policies and test scenarios for free vs paid users., Review account lifecycle automation and audit logs for state transitions., Functional tests of email verification flow and review of token expiry/one-time use implementation. **Priority:** Critical | **Status:** Pending --- #### REQ-003: User profile management capturing display name, profile photo, optional bio, occupation/status, and ... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-008**: Exposure of exact addresses or PII via search index or API responses (e.g., deta... - *...and 5 more threats* **Security Controls:** - **[ISO27001] A.18.1.4**: [ISO27001] Privacy and protection of personally identifiable information shall be ensured a... - **[OWASP] V1.4.3**: [OWASP] Verify that the application collects and processes only the minimum amount of pe... - **[NIST] AC-6**: [NIST] Employ the principle of least privilege, allowing only authorized access for use... - **[OWASP] V9.1.1**: [OWASP] Verify that the application protects personal data and supports data minimizatio... **Verification:** Access tests for different roles and review of API authorization rules., Design review and UX testing of privacy controls; data inventory check for minimization., Review data classification and storage protections; check logs for PII leakage., Review privacy documentation, data flows, and UI settings for PII exposure. **Priority:** Critical | **Status:** Pending --- #### REQ-004: Advert lifecycle management: create, save draft, submit for moderation, edit, publish (post-approval... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - *...and 5 more threats* **Security Controls:** - **[OWASP] V4.2.2**: [OWASP] Verify that users can only create, read, update, or delete resources that they o... - **[NIST] AC-3**: [NIST] Enforce approved authorizations for logical access to information and system res... - **[OWASP] V5.1.3**: [OWASP] Verify that all inputs are validated using positive validation (allow lists) for... - **[ISO27001] A.14.2.5**: [ISO27001] Security testing shall be carried out during development. **Verification:** Policy review and data-layer query inspection for authorization predicates., Unit/integration tests for owner vs non-owner scenarios; code review of authorization checks., Evidence of CI security tests and review records., Review validation schemas and fuzz test inputs; check that invalid data is rejected. **Priority:** Critical | **Status:** Pending --- #### REQ-005: Support property-level entry with multiple room entities per property; each room includes cost, size... **Related Threats:** - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-022**: Backups or audit logs containing historic PII retained longer than necessary, or... **Verification:** Manual Review **Priority:** Medium | **Status:** Pending --- #### REQ-006: Automatic moderation/ filtering pipeline using heuristics and ML to detect spam, scams, malicious li... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - *...and 5 more threats* **Verification:** Manual Review **Priority:** Medium | **Status:** Pending --- #### REQ-007: Moderator and Administrator dashboard to review, approve, disable, or delete adverts; manage user ac... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - *...and 5 more threats* **Security Controls:** - **[OWASP] V4.1.3**: [OWASP] Verify that administrative interfaces are protected with strong authentication a... - **[NIST] AC-5**: [NIST] Separate duties of individuals to reduce the risk of malevolent activity without... - **[ISO27001] A.9.2.6**: [ISO27001] The access rights of all employees and external party users to information and i... - **[NIST] AU-12**: [NIST] Provide audit record generation capability for defined auditable events within t... **Verification:** Audit event catalog review and sampling of admin action logs., Review role definitions and evidence of dual-control workflows., Access recertification records and deprovisioning audit trails., Check admin auth configuration, MFA enforcement, and role matrix. **Priority:** Critical | **Status:** Pending --- #### REQ-008: Geo-centric search with approximate location visualisation (neighbourhood or postcode area), map clu... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-008**: Exposure of exact addresses or PII via search index or API responses (e.g., deta... - **THR-012**: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti... - **THR-014**: Third-party map provider logs or telemetry reveal approximate queries or leak lo... - *...and 3 more threats* **Security Controls:** - **[OWASP] V1.4.2**: [OWASP] Verify that the application limits collection and retention of location and othe... - **[OWASP] V9.4.1**: [OWASP] Verify that sensitive data such as geolocation is not exposed in logs or through... - **[NIST] PL-8**: [NIST] Develop an information security architecture for the system that describes the r... - **[ISO27001] A.18.1.5**: [ISO27001] Cryptographic controls shall be used in compliance with all relevant agreements,... **Verification:** Review security architecture documents and threat models covering geo components., Review data model and retention jobs; verify only approximate location is exposed., API response and log sampling to confirm no precise coordinates are present., Crypto configuration review and TLS scanning of map endpoints. **Priority:** High | **Status:** Pending --- #### REQ-009: Advanced filters: price range, distance, number of housemates, amenities, stay duration, household p... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-009**: Adversarial content engineered to bypass automated moderation (image/text obfusc... - *...and 4 more threats* **Verification:** Manual Review **Priority:** Medium | **Status:** Pending --- #### REQ-010: Email alerts (instant and daily digest) and in-app notifications for new adverts matching saved sear... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - *...and 5 more threats* **Security Controls:** - **[OWASP] V10.4.1**: [OWASP] Verify that the application enforces business logic with appropriate limits and ... - **[OWASP] V5.4.3**: [OWASP] Verify that untrusted data is properly sanitized and output encoded to prevent i... - **[NIST] SI-4**: [NIST] Monitor the information system to detect attacks and indicators of potential att... - **[ISO27001] A.12.1.3**: [ISO27001] The use of resources shall be monitored, tuned and projections made of future ca... **Verification:** Review rate limit configurations and simulate high-frequency alert creation., Check monitoring rules and SIEM dashboards for alerting subsystem., Review templates and perform injection tests in alert content., Review capacity dashboards and auto-scaling policies. **Priority:** High | **Status:** Pending --- #### REQ-011: Favourites/bookmarks management: allow users to favourite adverts/rooms, organise lists (tags/folder... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - **THR-018**: Insufficient or tamperable audit logs allowing admins/moderators to deny or hide... - **THR-023**: Cache poisoning or sensitive content cached at CDN edge (e.g., user-specific pag... - *...and 3 more threats* **Security Controls:** - **[OWASP] V4.3.1**: [OWASP] Verify that users can only access their own records, such as personal lists, fav... - **[NIST] AC-16**: [NIST] Associate security attributes with information by information systems and enforc... - **[ISO27001] A.9.4.1**: [ISO27001] Access to information and application system functions shall be restricted in ac... - **[OWASP] V9.3.1**: [OWASP] Verify that sensitive stored data is protected from unauthorized access and tamp... **Verification:** Policy review and functional testing of access restrictions., Review storage encryption and access controls; test for tampering resistance., Conduct IDOR testing on list endpoints and inspect ORM scoping rules., Review database schema and policy enforcement logic for attribute checks. **Priority:** Critical | **Status:** Pending --- #### REQ-012: Secure in-app messaging system that mediates communications between seekers and advertisers and stor... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-005**: Replay attacks or token theft in transit due to inadequate transport security or... - *...and 5 more threats* **Security Controls:** - **[OWASP] V9.2.1**: [OWASP] Verify that all sensitive communications are encrypted in transit using secure p... - **[NIST] SC-13**: [NIST] Employ cryptographic mechanisms to prevent unauthorized disclosure of informatio... - **[OWASP] V2.8.1**: [OWASP] Verify that re-authentication or step-up authentication is required before perfo... - **[ISO27001] A.13.2.3**: [ISO27001] Information involved in electronic messaging shall be appropriately protected. **Verification:** Review cipher suites and test integrity verification on message transport., TLS configuration scan and packet inspection to confirm encryption., Functional test of step-up flow and token expiry behavior., Policy review and storage configuration checks; access audit for admin views. **Priority:** Critical | **Status:** Pending --- #### REQ-013: Interactive map view using third-party mapping APIs with clustering and obfuscation of exact coordin... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-008**: Exposure of exact addresses or PII via search index or API responses (e.g., deta... - **THR-009**: Adversarial content engineered to bypass automated moderation (image/text obfusc... - *...and 5 more threats* **Security Controls:** - **[OWASP] V1.4.1**: [OWASP] Verify that privacy requirements such as data minimization and anonymization are... - **[OWASP] V5.3.1**: [OWASP] Verify that data rendered in the UI, including maps and visualizations, is prope... - **[NIST] SC-7**: [NIST] Monitor and control communications at the external boundary and key internal bou... - **[ISO27001] A.14.2.1**: [ISO27001] Rules for the development of software and systems shall be established and appli... **Verification:** Network configuration review and monitoring of egress to mapping services., Design review and UI tests to confirm only approximate positions are shown., Check SDLC policy adherence and code review records for map modules., Dynamic application security testing for XSS in map components. **Priority:** High | **Status:** Pending --- #### REQ-014: Reporting and abuse-flagging workflow for users to report suspicious adverts or users, with automate... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - **THR-009**: Adversarial content engineered to bypass automated moderation (image/text obfusc... - *...and 5 more threats* **Security Controls:** - **[NIST] AU-3**: [NIST] Ensure that audit records contain information that establishes what events occur... - **[OWASP] V7.1.1**: [OWASP] Verify that all security-relevant events are logged, including authentication, a... - **[ISO27001] A.12.4.1**: [ISO27001] Event logs recording user activities, exceptions, faults and information securit... - **[NIST] AU-6**: [NIST] Review and analyze information system audit records for indications of inappropr... **Verification:** Check logging configuration and attempt to access logs with different roles., Inspect SIEM dashboards and alert configurations for moderation events., Review log review procedures and evidence of periodic reviews., Review audit log fields and sample records for completeness. **Priority:** High | **Status:** Pending --- #### REQ-015: Paid-tier features: priority listing / boosted placement, branding fields, extended descriptions, an... **Related Threats:** - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-010**: In-app moderated messaging used to exchange PII; messages stored in DB and in tr... - **THR-015**: Payment flow manipulation or token interception causing fraudulent premium listi... - **THR-020**: Search index poisoning or malicious adverts crafted to manipulate search ranking... - **THR-026**: Lack of immutable proof for subscription entitlement changes leads to disputes w... - *...and 1 more threats* **Security Controls:** - **[OWASP] V4.2.3**: [OWASP] Verify that the application enforces authorization checks for each function, esp... - **[OWASP] V10.4.3**: [OWASP] Verify that business logic enforces integrity of transactions and prevents abuse... - **[NIST] AU-2**: [NIST] Define auditable events and ensure that the information system generates audit r... - **[ISO27001] A.12.1.1**: [ISO27001] Operating procedures shall be documented and made available to all users who nee... **Verification:** SOP review and training records., Attempt to access premium features with non-paid accounts; review authorization middleware., Audit event catalog review and sampling of payment-related logs., Business logic tests simulating tampering with client-side flags and stale receipts. **Priority:** Critical | **Status:** Pending --- #### REQ-016: Secure payment processing via a PCI-DSS-compliant gateway for subscriptions and one-off payments; do... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-005**: Replay attacks or token theft in transit due to inadequate transport security or... - **THR-006**: Credential stuffing, weak password reuse, or brute-force attacks leading to acco... - *...and 5 more threats* **Security Controls:** - **[OWASP] V9.2.2**: [OWASP] Verify that connections to external payment service providers use strong TLS and... - **[OWASP] V9.3.2**: [OWASP] Verify that payment-related data stored is minimized and protected using strong ... - **[ISO27001] A.15.1.1**: [ISO27001] Information security requirements for mitigating the risks associated with suppl... - **[NIST] SA-9**: [NIST] Require that providers of external information system services comply with organ... **Verification:** TLS scan and connection tests to PSP endpoints; review client configuration., Third-party risk assessment records and periodic reassessment reports., Supplier agreement review and third-party assurance evidence., Data inventory and storage encryption configuration review; access audit. **Priority:** Critical | **Status:** Pending --- #### REQ-017: GDPR-compliant data handling: obtain explicit consent for processing where required, allow data subj... **Related Threats:** - **THR-002**: Client-side manipulation of UI (e.g., modifying JS to change advert metadata, pr... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - **THR-008**: Exposure of exact addresses or PII via search index or API responses (e.g., deta... - **THR-012**: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti... - **THR-013**: Publicly accessible S3/Blob containers containing photos that include metadata o... - *...and 5 more threats* **Security Controls:** - **[ISO27001] A.18.1.4**: [ISO27001] Privacy and protection of personally identifiable information shall be ensured a... - **[OWASP] V1.4.4**: [OWASP] Verify that consent is obtained, recorded, and can be withdrawn for personal dat... - **[NIST] AR-8**: [NIST] Provide an accounting of disclosures of personally identifiable information to i... - **[ISO27001] A.18.1.1**: [ISO27001] All relevant legislative statutory, regulatory and contractual requirements shal... **Verification:** Examine consent records and test withdrawal propagation to processing systems., Review disclosure log schema and perform a test DSAR., Audit the compliance register and control mappings., Review ROPA/DPIA documents and PII access controls. **Priority:** Critical | **Status:** Pending --- #### REQ-018: Logging, monitoring and audit trails for authentication events, moderation actions, payment transact... **Related Threats:** - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - **THR-009**: Adversarial content engineered to bypass automated moderation (image/text obfusc... - **THR-014**: Third-party map provider logs or telemetry reveal approximate queries or leak lo... - **THR-015**: Payment flow manipulation or token interception causing fraudulent premium listi... - **THR-016**: Advertisers dispute charges or claim service not delivered; lack of reliable inv... - *...and 5 more threats* **Security Controls:** - **[OWASP] V7.1.3**: [OWASP] Verify that logs are generated for administrative actions, access control events... - **[NIST] AU-8**: [NIST] Use internal system clocks to generate time stamps for audit records with suffic... - **[ISO27001] A.12.4.2**: [ISO27001] Logging facilities and log information shall be protected against tampering and ... - **[NIST] AU-9**: [NIST] Protect audit information and audit tools from unauthorized access, modification... **Verification:** Log sampling and SIEM ingestion verification for all target event types., Inspect log storage controls and integrity check outcomes., Check NTP configuration and compare timestamps across services., Access review for log tools and attempted unauthorized modification test. **Priority:** Critical | **Status:** Pending --- #### REQ-019: Security controls including encryption in transit (TLS), encryption at rest for PII and payment toke... **Related Threats:** - **THR-005**: Replay attacks or token theft in transit due to inadequate transport security or... - **THR-007**: Broken access control allowing privilege escalation (e.g., seeker modifies reque... - **THR-010**: In-app moderated messaging used to exchange PII; messages stored in DB and in tr... - **THR-012**: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti... - **THR-013**: Publicly accessible S3/Blob containers containing photos that include metadata o... - *...and 5 more threats* **Security Controls:** - **[OWASP] V9.1.2**: [OWASP] Verify that all sensitive data is identified and classified, and appropriate pro... - **[NIST] SC-12**: [NIST] Establish and manage cryptographic keys for required cryptography employed withi... - **[OWASP] V2.7.5**: [OWASP] Verify that session management and authentication support multi-factor authentic... - **[NIST] SI-10**: [NIST] Check the validity of information inputs. **Verification:** Code review of validation and gateway configs; fuzz testing of endpoints., Review data inventory and control mappings to classification levels., Test MFA enrollment and enforcement; review auth configuration., Key management policy review and evidence of key rotation/audit logs. **Priority:** Critical | **Status:** Pending --- #### REQ-020: Accessibility and responsive design to support common browsers and mobile devices, and target WCAG 2... **Related Threats:** - **THR-001**: Reflected or stored Cross-Site Scripting (XSS) via user-supplied advert content,... - **THR-003**: UI-level phishing via malicious adverts or profiles that mimic platform branding... - **THR-004**: Layer 7 volumetric or application-layer DDoS targeting search, messaging, or adv... - **THR-011**: Sensitive information leaked via email digests or push notifications (e.g., full... - **THR-012**: Unauthorized access to backups, snapshots, or misconfigured search index (Elasti... - *...and 5 more threats* **Security Controls:** - **[OWASP] V1.3.1**: [OWASP] Verify that security is addressed in user experience and design, including error... - **[OWASP] V7.3.1**: [OWASP] Verify that error messages are handled in a user-friendly manner without reveali... - **[ISO27001] A.14.2.1**: [ISO27001] Rules for the development of software and systems shall be established and appli... - **[NIST] RA-5**: [NIST] Scan for vulnerabilities in the information system and hosted applications and a... **Verification:** UX review of error messages and accessibility testing., Policy review and pipeline checks for accessibility/security gates., Scan reports and remediation tracking., UI testing for error content and accessibility audits. **Priority:** Low | **Status:** Pending --- --- ## Appendix E: References - [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) - [NIST Cybersecurity Framework](https://www.nist.gov/cyberframework) - [ISO/IEC 27001:2022](https://www.iso.org/standard/27001) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [MITRE ATT&CK Framework](https://attack.mitre.org/) --- *End of Report - Generated by Security Requirements Analysis System v2.0* *Generated: 2025-11-25 17:05:39*